[gentoo-alt] [PREFIX] The libgcc linking case

[Fabian Groffen]

A little message to get everyone up-to-date on what's been going on.

A few weeks ago I upgraded gcc from 4.2.2 to 4.2.3 on my Solaris 10
machine, and I ended up with a completely broken system.  The cause of
this was that usr/lib/gcc/i386-pc-solaris2.10/4.2.2/libgcc_s.so.1 no
longer existed, and (almost) every application in my Prefix happened to
be linked against it.  Obviously, libgcc_s.so.1 is just provided by
4.2.3, but stored in another directory.

Thinking about this, I also realised that each binpkg includes these
same links, effectively requiring one to use the same compiler as the
binpkg was built with.

This is undesirable, so a solution was to be found.  This is where the
journey starts...

gcc-config is the tool that switches the compilers our systems, and this
tool is responsible for actually placing libgcc into /lib, because it is
recognised that some systems always need this lib for almost any
application.  However, due to some nice screwup from the writer of this
message this never functioned at all, so bug one found.
But, does this solve everything?  Not really, I think.  There's more in
gcc than just libgcc; think of libstdc++, libobjc, libgcj, libfortran,
etc, etc.  So, it seemed like a simple idea to just copy over those libs
into /usr/lib (they don't belong in /lib, as the system should be able
to do most without them) and be done with it.

Ok, why do we need this actually, and mainstream not.  Well, simply
because they have ld.so.conf and it contains all the paths to the
installed compiler(s!) lib directories.  So, for instance this
/usr/lib/gcc/i386-pc-solaris2.10/4.2.3.  Obviously, in Prefix we can't
do that as long as we're unprivileged, so we solved that problem by
using rpath directions, which are stored during the compilation/linking
process inside all objects, such that the runtime linker can find back
those libraries.  Joy is that enough, well, yes, to actually create the
situation that I started this email with.  While ld.so.conf is dynamic
and can change at any moment, the rpath directions are static, embedded
in the objects.  They can be changed (using chrpath) but that is an
operation that needs to be applied to each and every object.  Because it
is not dynamic, it will always point to the directory that was used
during compilation.

To solve this, I modified gcc-config as I pointed out before.  Now the
problem with that approach was that cleaning up the libs would get hard,
as different gcc installations may have different libraries, so I
quickly decided that we should dedicate a directory for these libs, so I
would simply remove that directory and start with a clean sheet, once
gcc-config runs.  This location happens to be usr/<chost>/lib/gcc.  The
additional challenge is that when multiple gccs are installed, one might
want to use the libstdc++ version belonging to gcc 3.4 for some apps,
while most other apps are fine with gcc 4.2's libstdc++.  This basically
means that the versioned libs for those compilers should always be
available, as they would be in the ld.so.conf case.  For this reason
gcc-config overlays all known compilers, making sure that the currently
selected compiler installs the unversioned symlinks for the libraries,
e.g. one defaults to using those libs.

Now, with a static path, it is just trivial to have binutils-config, our
ldwrapper that adds Prefix paths to the linker, add this static path to
the search path and rpath as well, and all should be fine, right?

Well, I have to test what Linux and Solaris do with this, but on Darwin
this horribly failed.

First GCC puts its libs itself somewhere.  On Darwin all libs have
install_names, absolute paths pointing to the library to use.  Where GCC
is said to install the libs, is also where the install_names point to.
Now if all GCC's would install their libs into our static path, we would
get collisions, so that's not what we do.  In fact, we let GCC simply
install its libs into the directory as at the start of this mail.  While
these can be easily copied to any place on an ELF system, on Darwin this
results in applications linking against those libraries pointing to the
original installed location.  Luckily there is a utility to change this
install_name, and so I did.  Problem solved, I thought.  Well, not
really.  GCC knows it needs its own lib on every object it creates, so
passes on the path to its own lib to the linker to be sure it will find
it.  This unfortunately results in finding the original library and
hence an object not pointing to the place where we carefully put our
libs.

Due to a Portage check, we can't mess with the install_names in the GCC
installation, because when they don't match the installation is aborted.
Also, if we mess, we should mess in such a way that GCC will inject the
proper path (ideally none).  The worst thing I've seen with GCC is that
it even injects -L/usr/lib when doing g++ final linking.  And then we're
back on track with the multilib hell where the same thing happens.
Should our ldwrapper intercept these flags?  Linking is seriously messed
up to say the least.

By the way, I shot multilib in Prefix.  Due to more variations of this
search path problem, multilib will not work properly.  Also I think it's
quite useless in Prefix.  If you want to do another bitwidth, then just
bootstrap that one (such as with the Solaris 64-bits Prefixes).  We
don't need multilib for that.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-alt@l.g.o mailing list