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.
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.
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)
I'd like to leave that discussion for now. The Debian goal is to support incompatible ABIs and, past that, incompatible architectures. libhf is ambiguous as you could have a MIPS hard float library installed on the same system as an ARM hard float library.
If you want both ARM and MIPS hard-float then I'd think you want both big-endian and little-endian ARM hard-float - but your patch defines the same dynamic linker name for both of those.
Standard upstream practice supports having multiple variants that plausibly run on the same system at the same time, such as /lib and /lib64, and it seems reasonable to support hard and soft float variants that way via a directory such as /libhf. The Debian-style paths are not the default on any other architecture and I don't think it's appropriate to make them the default for this particular case only.
and these different Debian-style names could be implemented separately in a multiarch patch if someone submits one that properly accounts for my review comments on previous patch versions (failure to produce such a fixed patch being why Debian multiarch directory support has not got into GCC so far).
Agreed. Note that this loader path discussion is unrelated to multiarch. It came from the same people so there's a family resemblance.
I think it's directly related, and that such a path is inappropriate by default; that ARM should be consistent with other architectures, and that if you want to support paths in such subdirectories that would be a separate multiarch patch series for GCC, binutils and glibc (but the PT_INTERP would still use /lib<whatever>/<name> without subdirectories in any case).