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; 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)?
