How to choose the right libstdc++.so with soft-float?

[Andrew Haley]

Paul Smith writes:
 > On Fri, 2007-01-05 at 20:15 +0000, Andrew Haley wrote:
 > 
 > >  > I'll send an email to the binutils and glibc folks asking them about
 > >  > this.  Barring further information though it appears to me that this is
 > >  > a problem with GCC and needs a GCC solution (a la libgcc_s).
 > > 
 > > I'm very surprised by this last remark.  Why do you think so?  Looks
 > > like gcc has done exactly what it was designed to do, i.e. what it has
 > > been doing for many years.
 > > 
 > > It might simply be that soft-float isn't supported on your system.
 > 
 > I hope my messages haven't been that lame-sounding!  Definitely it's
 > supported; 

By your target OS, I mean.  The target OS needs to have support for
multilibbing.  You need a multilibbed libc, for example.

You also need to make sure that you have a nof version of ld.so.

 > I'm cross-compiling for a PPC440 chip, which has variants both with
 > and without hardware floating-point.  Further, as I've described,
 > when I build GCC it does generate both HWFP and SWFP versions of
 > the two compiler libraries, libgcc_s and libstdc++.  The problem
 > is, while libgcc_s.so is handled in a way that allows both HW and
 > SW FP to be used, libstdc++.so is not.  I see no logic in
 > intentionally having one work and the other not work, so it seems
 > reasonable to conclude that libstdc++ needs to be enhanced to work
 > as well as libgcc.

 > To recap, libgcc works like this: two different libraries with different
 > file names _AND_ different SONAMEs are created: libgcc_s.so and
 > libgcc_s-nof.so (no floating point).  When GCC (the front-end program)
 > is run without the -msoft-float option, it calls the linker with
 > -lgcc_s.  When it is run WITH the -msoft-float option, it calls the
 > linker with -lgcc_s-nof -lgcc_s (both of them).  So, if compiled without
 > -msoft-float the ELF headers have a NEEDS entry for "libgcc_s.so".  If
 > compiled WITH -msoft-float the ELF headers have a NEEDS entry for
 > "libgcc_s-nof.so" (and maybe also libgcc_s.so, if necessary).  Thus, the
 > runtime dynamic linker will look through its configured directories for
 > the right version of libgcc_s and load it.
 > 
 > In contrast, libstdc++ works like this: two different libraries are
 > created with the SAME file name and SONAME.  They are put in different
 > directories.  When the g++ front-end is invoked with the -msoft-float
 > option, it automatically adds an extra -L.../lib/nof directory to the
 > link line, so that at link time the SWFP version of libstdc++ is found.
 > So far so good.
 > 
 > But, at runtime there is no way for the dynamic linker to choose the
 > right libstdc++, as it can with libgcc_s, because the SONAMEs are the
 > same.  Even if both versions of libstdc++ exist on the system, the
 > dynamic linker will always pick whichever one is in the directory that
 > appears first on the list, not the right one for that application.
 > 
 > The user could add a special -R.../lib/nof to the g++ link line along
 > with the -msoft-float, but why should they be forced to do that,
 > especially when GCC already has a successfully strategy for dealing with
 > this issue (the one used by libgcc_s)?

It's not just libstdc++ that you'd have to give a magic soname, it's
every library on the system.  The sonames are usually controlled by
the Makefiles for each library, so to make this work you'd have to
hack every Makefile for every library.  While this would work if you
had only a few libraries, it's not a solution that scales very well.

A better solution is to have two different versions of ld.so, one in
/lib/ld.so and one in /lib/nof/ld.so and point the .interp section of
an executable at the appropriate one.  That's what we do on
multilibbed 32-bit and 64-bit GNU/Linux systems.

Andrew.