Another Gentoo (Open)Solaris implementation

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Another Gentoo (Open)Solaris implementation

Fabrizio Listello
Hi all,
I'm working (as many of you) on a fresh new implementation of gentoo on (Open)Solaris.
I've done bit of progresses in this. I'ld like to know how the progress are for other peoples.
A brief summary of my implementation features:
   * USERLAND=SunOS
   * KEYWORD=x86-sunos: this lead to a new portage overlay
   * profile=default-sunos/x86/5.11
   * files are all installed using --prefix=/usr
   * gnu commands that confilicts with solaris ones (only the core ones) are installed under /usr/gnu and they are not g- prefixed (I find a big thread about this, can anyone resume the results if a common line has been chosen?)
   * right now I've also chaged a bit the main ebuild.sh in order to use '$command's instead of 'command' (ie: id becomes $ID, a file in /etc/env.d defines the commands. Maybe this can be removed).


Cheers

--
I can receive www.openoffice.org files... and you ?
--

FList
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabian Groffen-2
Hi!

As far as I am aware, there are at least two other attempts.  The first
one is in a stage where it works pretty well on Solaris 8/9, and
installs in a prefix.  This thing called Portaris has been developed by
three non-Gentoo developers, and seems to use the mainline portage tree
(or at least a very recent snapshot of it).
The second is our own home-grown portage with prefix support thinghy,
that runs successfully on Solaris 9.  The portage tree that is used is
different from the mainline, and hence a "building in progress" thing.

I think this is as brief as I can make it for what I know.

Regards,


On 06-03-2006 23:18:28 +0100, Fabrizio Listello wrote:

> Hi all,
> I'm working (as many of you) on a fresh new implementation of gentoo on
> (Open)Solaris.
> I've done bit of progresses in this. I'ld like to know how the progress are
> for other peoples.
> A brief summary of my implementation features:
>    * USERLAND=SunOS
>    * KEYWORD=x86-sunos: this lead to a new portage overlay
>    * profile=default-sunos/x86/5.11
>    * files are all installed using --prefix=/usr
>    * gnu commands that confilicts with solaris ones (only the core ones) are
> installed under /usr/gnu and they are not g- prefixed (I find a big thread
> about this, can anyone resume the results if a common line has been chosen?)
>    * right now I've also chaged a bit the main ebuild.sh in order to use
> '$command's instead of 'command' (ie: id becomes $ID, a file in /etc/env.d
> defines the commands. Maybe this can be removed).


--
Fabian Groffen
Gentoo for Mac OS X Project
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Venky-2
In reply to this post by Fabrizio Listello
Hi FList,

I'd started out an OpenSolaris port, but I've been kinda tied up
with other things for sometime now.  Haven't been been able to spend
too much time on this.

Anyway, I was using the USERLAND value set to "OpenSolaris" and all
portage dependencies g-prefixed (gmake, gsed, gawk, etc.)  I also
had to make a small patch to the portage_data.py script to get
emerge running:

=============================================================
*** /usr/lib/portage/pym/portage_data.py.orig   Sat Dec  3 16:14:37 2005
--- /usr/lib/portage/pym/portage_data.py        Sat Dec  3 16:15:28 2005
***************
*** 21,26 ****
--- 21,30 ----
  elif ostype in ["FreeBSD","OpenBSD"]:
        userland="BSD"
        os.environ["XARGS"]="xargs"
+ elif ostype == "SunOS":
+       userland="OpenSolaris"
+       os.environ["XARGS"]="xargs"
+       lchown=os.chown
  else:
        writemsg(red("Operating system")+" \""+ostype+"\" "+red("currently unsupported. Exiting.")+"\n")
        sys.exit(1)
=============================================================

That's pretty much where things stand now! :(

Venky.

On Mon, Mar 06, 2006 at 11:18:28PM +0100, Fabrizio Listello wrote:

> Hi all,
> I'm working (as many of you) on a fresh new implementation of gentoo on
> (Open)Solaris.
> I've done bit of progresses in this. I'ld like to know how the progress are
> for other peoples.
> A brief summary of my implementation features:
>    * USERLAND=SunOS
>    * KEYWORD=x86-sunos: this lead to a new portage overlay
>    * profile=default-sunos/x86/5.11
>    * files are all installed using --prefix=/usr
>    * gnu commands that confilicts with solaris ones (only the core ones) are
> installed under /usr/gnu and they are not g- prefixed (I find a big thread
> about this, can anyone resume the results if a common line has been chosen?)
>    * right now I've also chaged a bit the main ebuild.sh in order to use
> '$command's instead of 'command' (ie: id becomes $ID, a file in /etc/env.d
> defines the commands. Maybe this can be removed).
>
>
> Cheers
>
> --
> I can receive www.openoffice.org files... and you ?
> --
>
> FList
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabrizio Listello
A doub that I have is regarding libc. For what I know virtual/libc should be a "provided" package. The Solaris libc does not obviously have the ldconfig command. What's the pourpose of this command that is so important in Gentoo/Linux?
Has someone managed to have "sandbox" working under non-Linux OSs?

Thanks

On 3/7/06, Venky <[hidden email]> wrote:
Hi FList,

I'd started out an OpenSolaris port, but I've been kinda tied up
with other things for sometime now.  Haven't been been able to spend
too much time on this.

Anyway, I was using the USERLAND value set to "OpenSolaris" and all
portage dependencies g-prefixed (gmake, gsed, gawk, etc.)  I also
had to make a small patch to the portage_data.py script to get
emerge running:

=============================================================
*** /usr/lib/portage/pym/portage_data.py.orig   Sat Dec  3 16:14:37 2005
--- /usr/lib/portage/pym/portage_data.py        Sat Dec  3 16:15:28 2005
***************
*** 21,26 ****
--- 21,30 ----
  elif ostype in ["FreeBSD","OpenBSD"]:
        userland="BSD"
        os.environ["XARGS"]="xargs"
+ elif ostype == "SunOS":
+       userland="OpenSolaris"
+       os.environ["XARGS"]="xargs"
+       lchown=os.chown
  else:
        writemsg(red("Operating system")+" \""+ostype+"\" "+red("currently unsupported. Exiting.")+"\n")
        sys.exit(1)
=============================================================

That's pretty much where things stand now! :(

Venky.

On Mon, Mar 06, 2006 at 11:18:28PM +0100, Fabrizio Listello wrote:
> Hi all,
> I'm working (as many of you) on a fresh new implementation of gentoo on
> (Open)Solaris.
> I've done bit of progresses in this. I'ld like to know how the progress are
> for other peoples.
> A brief summary of my implementation features:
>    * USERLAND=SunOS
>    * KEYWORD=x86-sunos: this lead to a new portage overlay

>    * profile=default-sunos/x86/5.11
>    * files are all installed using --prefix=/usr
>    * gnu commands that confilicts with solaris ones (only the core ones) are
> installed under /usr/gnu and they are not g- prefixed (I find a big thread
> about this, can anyone resume the results if a common line has been chosen?)
>    * right now I've also chaged a bit the main ebuild.sh in order to use
> '$command's instead of 'command' (ie: id becomes $ID, a file in /etc/env.d
> defines the commands. Maybe this can be removed).
>
>
> Cheers
>
> --
> I can receive www.openoffice.org files... and you ?
> --
>
> FList
--
[hidden email] mailing list




--
I can receive www.openoffice.org files... and you ?
--

FList
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Patrick Lauer
On Wed, 2006-03-08 at 10:55 +0100, Fabrizio Listello wrote:
> A doub that I have is regarding libc. For what I know virtual/libc
> should be a "provided" package.
Yes, you use the provided Solaris libc.
> The Solaris libc does not obviously have the ldconfig command. What's
> the pourpose of this command that is so important in Gentoo/Linux?
It's linux-specific, from the man page: "configure dynamic linker run
time bindings"
It build a list of all known dynamic libraries and a cache to accelerate
the ld.so dynamic linker. You should be able to safely remove all
ldconfig calls as far as I can tell; if there is an equivalent on
Solaris you may wish to use it instead.

> Has someone managed to have "sandbox" working under non-Linux OSs?
It uses a glibc-specific LD_PRELOAD directive as far as I know to hook
system calls.
This is linux/glibc specific and not portable. Rewriting the code for
other Operating Systems should be possible, but for now you may wish to
completely disable sandbox.

Hope that helps,

Patrick

--
Stand still, and let the rest of the universe move

signature.asc (207 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Diego Elio Pettenò-3
In reply to this post by Fabrizio Listello
On Wednesday 08 March 2006 10:55, Fabrizio Listello wrote:
> The Solaris libc does not obviously have the
> ldconfig command. What's the pourpose of this command that is so important
> in Gentoo/Linux?
ldconfig is not only a Linux command, as there are (different) implementations
on BSDs, too.
It's used to (usually) transform the /etc/ld.so.conf file in a format readable
by the dynamic loader (ld.so). On Linux it generates a cache file
(/etc/ld.so.cache), while on FreeBSD and DragonFly it generates a "hints"
file (/var/run/ld-elf.so.hints); on NetBSD and OpenBSD I'm not actually sure
of the implementation, but it doesn't use a ld.so.conf file, iirc.

I think there might be something similar on Solaris, too, as that is needed to
tell ld.so to load libraries found in different path without setting
LD_LIBRARY_PATH. Also, linker and loader of Solaris seems to be quite similar
to the ones used by GNU operating systems (binutils and glibc), probably
there's a similar command.

The generation of the ld.so configuration data has to be updated in both
portage (for env-update command) and possibly eselect (env module).

> Has someone managed to have "sandbox" working under non-Linux OSs?
Sort of, it does work in theory, as the code should build on most ELF OSes,
but there are a series of other problems at least for FreeBSD: some of the
functions that are wrapped around by sandbox, from within the libc calls
another function wrapped by sandbox that in turns call the first one, and we
get a loop until the stack overflows. In glibc the internal calls are passed
through a different symbol so that overloading them with a preload doesn't
affect the libc itself, unfortunately this doesn't happen on FreeBSD... it
should be easy to fix that if someone would like to edit the sources, but it
might be a big problem if Solaris does the same thing as FreeBSD (as you
can't generally edit the library if you're using the old binaries).

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

attachment0 (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Venky-2
> I think there might be something similar on Solaris, too, as that is needed to
> tell ld.so to load libraries found in different path without setting
> LD_LIBRARY_PATH. Also, linker and loader of Solaris seems to be quite similar
> to the ones used by GNU operating systems (binutils and glibc), probably
> there's a similar command.

The linker/loader system on Solaris _is_ similiar to Linux.
However, the linker configuration files in Solaris
(/var/ld/ld.config and /var/ld/64/ld.config) are not meant to be
hand-edited.  The "crle" command needs to be used to both
configure the paths as well as update the cache.

If we absolutely need ldconfig in Gentoo/OpenSolaris, we could
write our own (a small wrapper around crle) which reads in data
from /etc/ld.so.conf and uses crle to update the cache.

> > Has someone managed to have "sandbox" working under non-Linux OSs?
> Sort of, it does work in theory, as the code should build on most ELF OSes,
> but there are a series of other problems at least for FreeBSD: some of the
> functions that are wrapped around by sandbox, from within the libc calls
> another function wrapped by sandbox that in turns call the first one, and we
> get a loop until the stack overflows.

Can you list out some specific libc calls which have this problem
on FreeBSD, Diego?  I can check this up and see if OpenSolaris
has the same issues.

Thanks,
Venky.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Diego Elio Pettenò-3
On Thursday 09 March 2006 16:43, Venky wrote:
> If we absolutely need ldconfig in Gentoo/OpenSolaris, we could
> write our own (a small wrapper around crle) which reads in data
> from /etc/ld.so.conf and uses crle to update the cache.
I don't think such a wrapper is needed, as env-update is a wrapper by itself,
so the only thing needed is to change portage to make sure that env-update
instead of calling ldconfig calls crle to manage the paths.
The same would be for eselect env update.

Also, this is similar to the ldconfig in obsd/nbsd that does not use an
ld.so.conf file to read the data, but gets them from the commandline.

> Can you list out some specific libc calls which have this problem
> on FreeBSD, Diego?  I can check this up and see if OpenSolaris
> has the same issues.
Hmm I remember getcwd calling opendir that was then calling getcwd and so on.
I don't think it was the only loop, tho.

If the library used a _getcwd() symbol to get the right function to call while
being within the libc itself, it would have been transparent, so if
OpenSolaris is doing so, it's safe.

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

attachment0 (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabrizio Listello
Right now I'vedone this small ldconfig implementation for solaris. Just for playing.

[code]
#!/usr/bin/bash
. /sbin/functions.sh
/usr/bin/sed "/^\ *#/d" /etc/ld.so.conf | while read lddir; do
        einfo "Adding $lddir"
        /usr/bin/crle -u -l $lddir
        einfo "Caching $lddir"
        /usr/bin/crle -u -i $lddir
done
[/code]

Right now I'm having a strange behaviour while compiling. For example during the ./configure phase of neon library I've

configure:26042: i386-pc-solaris2.11-gcc -o conftest -O2 -march=i686 -pipe  -D_LARGEFILE64_SOURCE -DNE_LFS  conftest.c  -lsocket  >&5
/usr/gnu/bin/ld: warning: libnsl.so.1, needed by /usr/lib/gcc/i386-pc-solaris2.11 /4.0.2/../../../libsocket.so, not found (try using -rpath or -rpath-link)

The strange thing is that libnsl *is* present and is under /lib that is a standard search path for the linker:
# ld --verbose | grep SEARCH
SEARCH_DIR("/usr/i386-pc-solaris2.11/lib"); SEARCH_DIR("/usr/lib/binutils/i386-pc-solaris2.11/2.16.1"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/usr/ccs/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");

note that I'm using a fresh new toolchain I've compiled
# gcc --verbose
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: /var/tmp/portage/gcc-4.0.2-r9999/work/gcc-4.0.2/configure --prefix=/usr --bindir=/usr/i386- pc-solaris2.11/gcc-bin/4.0.2 --includedir=/usr/lib/gcc/i386-pc-solaris2.11/4.0.2/include --datadir=/usr/share/gcc-data/i386-pc-solaris2.11/4.0.2 --mandir=/usr/share/gcc-data/i386-pc-solaris2.11/4.0.2/man --infodir=/usr/share/gcc-data/i386- pc-solaris2.11/4.0.2/info --with-gxx-include-dir=/usr/lib/gcc/i386-pc-solaris2.11/4.0.2/include/g++-v4 --host=i386-pc-solaris2.11 --build=i386-pc-solaris2.11 --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --with-as=/usr/gnu/bin/as --with-gnu-as --with-gnu-ld --with-ld=/usr/gnu/bin/ld --disable-multilib
Thread model: posix
gcc version 4.0.2 (Gentoo 4.0.2-r9999, pie-8.7.8)

Any idea?

thanks

On 3/9/06, Diego 'Flameeyes' Pettenò <[hidden email]> wrote:
On Thursday 09 March 2006 16:43, Venky wrote:
> If we absolutely need ldconfig in Gentoo/OpenSolaris, we could
> write our own (a small wrapper around crle) which reads in data
> from /etc/ld.so.conf and uses crle to update the cache.
I don't think such a wrapper is needed, as env-update is a wrapper by itself,
so the only thing needed is to change portage to make sure that env-update
instead of calling ldconfig calls crle to manage the paths.
The same would be for eselect env update.

Also, this is similar to the ldconfig in obsd/nbsd that does not use an
ld.so.conf file to read the data, but gets them from the commandline.

> Can you list out some specific libc calls which have this problem
> on FreeBSD, Diego?  I can check this up and see if OpenSolaris
> has the same issues.
Hmm I remember getcwd calling opendir that was then calling getcwd and so on.
I don't think it was the only loop, tho.

If the library used a _getcwd() symbol to get the right function to call while
being within the libc itself, it would have been transparent, so if
OpenSolaris is doing so, it's safe.

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE





--
I can receive www.openoffice.org files... and you ?
--

FList
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Diego Elio Pettenò-3
On Thursday 09 March 2006 17:25, Fabrizio Listello wrote:
> Right now I'm having a strange behaviour while compiling. For example
> during the ./configure phase of neon library I've
That error happens while it's unable to find a library in DT_NEEDED; by
default binutils' ld looks for them in extra directories (and SEARCH_DIRS)
only if they are given by the runtime linker cache...

Where ld come from? I know vanilla binutils has the right code only to handle
GNU-like systems with ld.so.cache (I'm working on a patch that will work on
2.16.1 and 2.16.91.6 to have support for FreeBSD's hints files).
You might need a similar patch for solaris.

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

attachment0 (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Venky-2
> Where ld come from? I know vanilla binutils has the right code only to handle
> GNU-like systems with ld.so.cache (I'm working on a patch that will work on
> 2.16.1 and 2.16.91.6 to have support for FreeBSD's hints files).
> You might need a similar patch for solaris.

I would normally recommend using the native Solaris ld instead of
GNU ld.  I *have* had a few applications break because they
expect GNU ld specific options, but these are few and far
between.

Venky.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabrizio Listello
Ok, thanks I'm remerging gcc-4.0.2 with --without-gnu-ld --with-ld=/usr/ccs/bin/ld

On 3/9/06, Venky <[hidden email]> wrote:
> Where ld come from? I know vanilla binutils has the right code only to handle
> GNU-like systems with ld.so.cache (I'm working on a patch that will work on
> 2.16.1 and 2.16.91.6 to have support for FreeBSD's hints files).
> You might need a similar patch for solaris.

I would normally recommend using the native Solaris ld instead of
GNU ld.  I *have* had a few applications break because they
expect GNU ld specific options, but these are few and far
between.

Venky.
--
[hidden email] mailing list




--
I can receive www.openoffice.org files... and you ?
--

FList
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabrizio Listello
Great!
While I was able to build gcc with gnu-ld and gnu-as... now I've this problem:

ld: fatal: relocation error: file: .libs/mt_allocator.o section: .rel.eh_frame symbol: .LFB17: relocation against a discarded symbol,
        symbol is part of discarded section: .gnu.linkonce.t._ZN9__gnu_cxx4lockC1ER14_pthread_mutex

This is the result of the configure part
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS=""
Configuring gcc ...
running gcc-compiler-configure
configuring for GCC_LANG: c,c++

PREFIX:          /usr
BINPATH:         /usr/i386- pc-solaris2.11/gcc-bin/4.0.2
LIBPATH:         /usr/lib/gcc/i386-pc-solaris2.11/4.0.2
DATAPATH:        /usr/share/gcc-data/i386-pc-solaris2.11/4.0.2
STDCXX_INCDIR:   /usr/lib/gcc/i386-pc-solaris2.11/4.0.2/include/g++-v4

Configuring GCC with:
        --prefix=/usr
        --bindir=/usr/i386-pc-solaris2.11/gcc-bin/4.0.2
        --includedir=/usr/lib/gcc/i386-pc-solaris2.11/4.0.2/include
        --datadir=/usr/share/gcc-data/i386- pc-solaris2.11/4.0.2
        --mandir=/usr/share/gcc-data/i386-pc-solaris2.11/4.0.2/man
        --infodir=/usr/share/gcc-data/i386-pc-solaris2.11/4.0.2/info
        --with-gxx-include-dir=/usr/lib/gcc/i386-pc-solaris2.11 /4.0.2/include/g++-v4
        --host=i386-pc-solaris2.11
        --build=i386-pc-solaris2.11
        --disable-altivec
        --enable-nls
        --without-included-gettext
        --with-system-zlib
        --disable-checking
        --disable-werror
        --disable-libunwind-exceptions
        --disable-multilib
        --disable-libmudflap
        --disable-libssp
        --disable-libgcj
        --enable-languages=c,c++
        --enable-shared
       --enable-threads=posix
        --enable-__cxa_atexit   --with-as=/usr/gnu/bin/as --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --disable-multilib

Ach!


On 3/9/06, Fabrizio Listello <[hidden email]> wrote:
Ok, thanks I'm remerging gcc-4.0.2 with --without-gnu-ld --with-ld=/usr/ccs/bin/ld


On 3/9/06, Venky <[hidden email]> wrote:
> Where ld come from? I know vanilla binutils has the right code only to handle
> GNU-like systems with ld.so.cache (I'm working on a patch that will work on
> 2.16.1 and <a href="http://2.16.91.6" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.16.91.6 to have support for FreeBSD's hints files).
> You might need a similar patch for solaris.

I would normally recommend using the native Solaris ld instead of
GNU ld.  I *have* had a few applications break because they
expect GNU ld specific options, but these are few and far
between.

Venky.
--
[hidden email] mailing list




--
I can receive <a href="http://www.openoffice.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.openoffice.org files... and you ?
--

FList



--
I can receive www.openoffice.org files... and you ?
--

FList
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabrizio Listello
GCC 4.1.0 emerged fine!!!

On 3/9/06, Fabrizio Listello <[hidden email]> wrote:
Great!
While I was able to build gcc with gnu-ld and gnu-as... now I've this problem:

ld: fatal: relocation error: file: .libs/mt_allocator.o section: .rel.eh_frame symbol: .LFB17: relocation against a discarded symbol,
        symbol is part of discarded section: .gnu.linkonce.t._ZN9__gnu_cxx4lockC1ER14_pthread_mutex

This is the result of the configure part
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS=""
Configuring gcc ...
running gcc-compiler-configure
configuring for GCC_LANG: c,c++

PREFIX:          /usr
BINPATH:         /usr/i386- pc-solaris2.11/gcc-bin/4.0.2
LIBPATH:         /usr/lib/gcc/i386-pc-solaris2.11/4.0.2
DATAPATH:        /usr/share/gcc-data/i386-pc-solaris2.11/4.0.2
STDCXX_INCDIR:   /usr/lib/gcc/i386-pc-solaris2.11/4.0.2/include/g++-v4

Configuring GCC with:

        --prefix=/usr
        --bindir=/usr/i386-pc-solaris2.11/gcc-bin/4.0.2
        --includedir=/usr/lib/gcc/i386-pc-solaris2.11 /4.0.2/include
        --datadir=/usr/share/gcc-data/i386- pc-solaris2.11/4.0.2
        --mandir=/usr/share/gcc-data/i386-pc-solaris2.11/4.0.2/man
        --infodir=/usr/share/gcc-data/i386-pc-solaris2.11/4.0.2/info
        --with-gxx-include-dir=/usr/lib/gcc/i386-pc-solaris2.11 /4.0.2/include/g++-v4
        --host=i386-pc-solaris2.11
        --build=i386-pc-solaris2.11
        --disable-altivec
        --enable-nls
        --without-included-gettext

        --with-system-zlib
        --disable-checking
        --disable-werror
        --disable-libunwind-exceptions
        --disable-multilib
        --disable-libmudflap
        --disable-libssp
        --disable-libgcj
        --enable-languages=c,c++
        --enable-shared
       --enable-threads=posix
        --enable-__cxa_atexit   --with-as=/usr/gnu/bin/as --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --disable-multilib

Ach!



On 3/9/06, Fabrizio Listello <[hidden email]> wrote:
Ok, thanks I'm remerging gcc-4.0.2 with --without-gnu-ld --with-ld=/usr/ccs/bin/ld


On 3/9/06, Venky <[hidden email]> wrote:
> Where ld come from? I know vanilla binutils has the right code only to handle
> GNU-like systems with ld.so.cache (I'm working on a patch that will work on
> 2.16.1 and <a href="http://2.16.91.6" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.16.91.6 to have support for FreeBSD's hints files).
> You might need a similar patch for solaris.

I would normally recommend using the native Solaris ld instead of
GNU ld.  I *have* had a few applications break because they
expect GNU ld specific options, but these are few and far
between.

Venky.
--
[hidden email] mailing list




--
I can receive <a href="http://www.openoffice.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.openoffice.org files... and you ?
--

FList



--
I can receive <a href="http://www.openoffice.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.openoffice.org files... and you ?
--

FList



--
I can receive <a href="http://www.openoffice.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.openoffice.org files... and you ?
--

FList
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Kito-2
In reply to this post by Fabrizio Listello
Err, I have no idea how I missed this thread...sorry for the late  
response.

On Mar 6, 2006, at 4:18 PM, Fabrizio Listello wrote:

> Hi all,
> I'm working (as many of you) on a fresh new implementation of  
> gentoo on (Open)Solaris.
> I've done bit of progresses in this. I'ld like to know how the  
> progress are for other peoples.

Check the forum thread[1] and the wiki[2] if you haven't already....

> A brief summary of my implementation features:
>    * USERLAND=SunOS
>    * KEYWORD=x86-sunos: this lead to a new portage overlay

I'd like to see this discussed more, Glep47 was proposed, but I'm not  
sure its robust enough to handle all the potential situations. I  
liked the use of the PLATFORM variable in the portaris version.  
Perhaps that in addition to the current use_expanded vars(eblic,  
kernel, etc.) would be flexible enough to handle everything.

>    * profile=default-sunos/x86/5.11

I'd like to see a solaris profile in the alt repo and/or the prefix  
repo.

>    * files are all installed using --prefix=/usr

Would the prefix branch be of interest? This would allow you to use  
arbitrary prefixes/users for portage instances.

>    * gnu commands that confilicts with solaris ones (only the core  
> ones) are installed under /usr/gnu and they are not g- prefixed (I  
> find a big thread about this, can anyone resume the results if a  
> common line has been chosen?)

I still prefer the use flag and have it left up to the profile/user  
to decide.

>    * right now I've also chaged a bit the main ebuild.sh in order  
> to use '$command's instead of 'command' (ie: id becomes $ID, a file  
> in /etc/env.d defines the commands. Maybe this can be removed).

Feel free to send patches to this list or me directly.


--Kito

[1] http://forums.gentoo.org/viewtopic.php?t=113387
[2] http://www.portaris.org/wiki/Main_Page


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Diego Elio Pettenò-3
On Sunday 12 March 2006 01:56, Kito wrote:
> I'd like to see this discussed more, Glep47 was proposed, but I'm not
> sure its robust enough to handle all the potential situations.
A feasible corner case example would be helpful here.

> >    * gnu commands that confilicts with solaris ones (only the core
> > ones) are installed under /usr/gnu and they are not g- prefixed (I
> > find a big thread about this, can anyone resume the results if a
> > common line has been chosen?)
> I still prefer the use flag and have it left up to the profile/user
> to decide.
I was thinking for a while about this, and I have a sort of idea that should
work _but_ requires at least a change to 2.1 portage for Gentoo/FreeBSD...

Provide two useflags: gnu-altdir and gnu-binprefix, masked in default-linux
profiles (so that users doesn't get unexpected situations), the first tells
the ebuild to install in an alternate location (/usr/gnu for instance), while
the second would prefix with a "g" the name of the command.

When the two useflags are disabled, the packages will block systems' packages,
example from a possible coreutils:

!gnu-altdir? ( !gnu-binprefix?
( !sys-freebsd/freebsd-bin !sys-freebsd/freebsd-ubin !sys-freebsd/sbin !sys-freebsd/usbin ) )

Which change to portage is needed? A per-package use.force support: for
example in Gentoo/FreeBSD, sed should _always_ be -gnu-altdir +gnu-binprefix,
so we need a way to force this to users.

Remains a problem for things like bsdtar that has a different logic and needs
prefix on default-linux and not on freebsd, but not a big deal.

Is this flexible enough?

--
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

attachment0 (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Kito-2
In reply to this post by Fabrizio Listello

On Mar 6, 2006, at 4:18 PM, Fabrizio Listello wrote:

> Hi all,
> I'm working (as many of you) on a fresh new implementation of  
> gentoo on (Open)Solaris.
> I've done bit of progresses in this. I'ld like to know how the  
> progress are for other peoples.

Well, I was bored last night and installed bv31a on an extra x86 I  
had around. I was able to bootstrap portage-prefix much easier than I  
had expected. I'll be adding a basic profile to the prefix tree soon.

> A brief summary of my implementation features:
>    * USERLAND=SunOS
>    * KEYWORD=x86-sunos: this lead to a new portage overlay
>    * profile=default-sunos/x86/5.11
>    * files are all installed using --prefix=/usr
>    * gnu commands that confilicts with solaris ones (only the core  
> ones) are installed under /usr/gnu and they are not g- prefixed (I  
> find a big thread about this, can anyone resume the results if a  
> common line has been chosen?)
>    * right now I've also chaged a bit the main ebuild.sh in order  
> to use '$command's instead of 'command' (ie: id becomes $ID, a file  
> in /etc/env.d defines the commands. Maybe this can be removed).

I like the idea of using env.d for this. I just let portage build its  
own toolchain, but this is a good idea when using the host-os'  
toolchain is preferred.

Can you share some of your work and hopefully we can consolidate this  
work?

--Kito




--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Another Gentoo (Open)Solaris implementation

Fabrizio Listello
You can see the progress and the first released files at

https://developer.berlios.de/projects/alba-experiment/

I'd no much time to update the site with instructions and things like that... help is apreciated..

Bye

On 3/14/06, Kito <[hidden email]> wrote:

On Mar 6, 2006, at 4:18 PM, Fabrizio Listello wrote:

> Hi all,
> I'm working (as many of you) on a fresh new implementation of
> gentoo on (Open)Solaris.
> I've done bit of progresses in this. I'ld like to know how the
> progress are for other peoples.

Well, I was bored last night and installed bv31a on an extra x86 I
had around. I was able to bootstrap portage-prefix much easier than I
had expected. I'll be adding a basic profile to the prefix tree soon.

> A brief summary of my implementation features:
>    * USERLAND=SunOS
>    * KEYWORD=x86-sunos: this lead to a new portage overlay
>    * profile=default-sunos/x86/5.11
>    * files are all installed using --prefix=/usr
>    * gnu commands that confilicts with solaris ones (only the core
> ones) are installed under /usr/gnu and they are not g- prefixed (I
> find a big thread about this, can anyone resume the results if a
> common line has been chosen?)
>    * right now I've also chaged a bit the main ebuild.sh in order
> to use '$command's instead of 'command' (ie: id becomes $ID, a file
> in /etc/env.d defines the commands. Maybe this can be removed).

I like the idea of using env.d for this. I just let portage build its
own toolchain, but this is a good idea when using the host-os'
toolchain is preferred.

Can you share some of your work and hopefully we can consolidate this
work?

--Kito




--
[hidden email] mailing list




--
I can receive www.openoffice.org files... and you ?
--

FList