On Wed, 4 Apr 2012 09:06:05 +0000 (UTC) "Joseph S. Myers" joseph@codesourcery.com wrote:
On Wed, 4 Apr 2012, Michael Hope wrote:
The tricky one is new GCC with old GLIBC. GCC may have to do a configure time test and fall back to /lib/ld-linux.so.3 if the hard float loader is missing.
I don't think that's appropriate for ABI issues. If a different dynamic linker name is specified, GCC should use it unconditionally (and require new enough glibc or a glibc installation that was appropriately rearranged).
I have no idea whether shlib-versions files naming a file in a subdirectory will work - but if not, you'd need to send a patch to libc-alpha to support dynamic linkers in subdirectories, with appropriate justification for why you are doing something different from all other architectures.
Understood. For now this is just a path. There's more infrastructure work needed if the path includes a directory.
Formally it's just a path - but an important feature of GNU/Linux and the GNU toolchain is consistency between different architectures and existing upstream practice is that the dynamic linker is always in the same directory as the other associated libraries and that this has the form /lib<something>. In the absence of a compelling reason, which I have not seen stated, to do otherwise for a single case, I think that existing practice should be followed with the dynamic linker being in a directory such as /libhf.
Consistency across architectures is why Fedora does many of the things the way it does, It really doesn't make much sense to me to diverge from that.
The "more infrastructure work needed" makes clear that you need libc-alpha buy-in *before* putting any patches into GCC or ports. But maybe if you don't try to put the dynamic linker in a different directory from the other libraries, it's easier to support via existing mechanisms (setting slibdir differently if --enable-multiarch-directories or similar)?
Do the MIPS or PowerPC loaders detect the ABI and change the library path based on that? I couldn't tell from the code.
No, they don't detect the ABI. Both ABIs (and, for Power, the e500v1 and e500v2 variants - compatible with soft-float at the function-calling level but with some glibc ABI differences with soft-float and with each other) use the same directories.
(e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to make two sets of libraries work in parallel if you have separate library directories like that.
Is this required, or should it be left to the distro to choose? Once the loader is in control then it can account for any distro specific features, which may be the standard /lib and /usr/lib for single ABI distros like Fedora or /usr/lib/$tuple for multiarch distros like Ubuntu and Debian.
I thought Fedora used the standard upstream /lib64 on x86_64 and so would naturally use a standard upstream /libhf where appropriate.
Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but wouldn't object to /libhf though today we have f17 about to go beta and all of rawhide built using /lib
Fedora also has software floating point being installed into /lib also
So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to handle that directory, I think)
Dennis