Mailing List Archive

breaking out libgcc and friends
alright, so embedded needs/wants a broken out libgcc and there are
apparently archs that need libgcc in /lib for binaries used to bring up
the system (i hear maybe arm and ia64?? more info here would be
appreciated). the question is how are we going to break stuff out
-cleanly- without, erm... breaking stuff.

how are we going to handle slots?
how about multiple installed versions of libgcc when they all have the
same soversion? i dont think we can do that if they live in /lib...
another problem: how are we going to handle archs where the soversion is
2 for the same libgcc that has soversion 1 on another arch (where does
this happen btw? alpha and...)? how could we possibly slot that
correctly with the current support available in portage?
what about gcc itself? we'll still need to compile the static libs and
put them in a versioned directory, along with .so symlinks.

i've been working on trying to make stuff more modular and maintainable
with toolchain.eclass, but i need feedback. lots of it, and from more
than just toolchain@gentoo.org...

here's a quickie libgcc ebuild for starters. with multilib enabled here,
it just installs:

/lib32/libgcc_s.so.1 -> libgcc_s-3.4.2.so.1
/lib32/libgcc_s-3.4.2.so.1
/lib64/libgcc_s.so.1 -> libgcc_s-3.4.2.so.1
/lib64/libgcc_s-3.4.2.so.1

(the libgcc_s_32.so symlink to /lib32/libgcc_s.so.1 would need to be
created by gcc itself and placed in the versioned directory)

anyone who wishes to beat some sanity into me is welcome to do so ;)
Re: breaking out libgcc and friends [ In reply to ]
I noticed that gcc make system can't seem to figure out what to
install.

here is the end of ebuild libgcc-3.4.2.ebuild package

make[1]: Leaving directory
`/var/tmp/portage/libgcc-3.4.2/work/build/gcc'
man:
prepallstrip:
strip:
>>> Completed installing into /var/tmp/portage/libgcc-3.4.2/image/

./
>>> Done.

a bug ?

--
gentoo-dev@gentoo.org mailing list