On Wed, 4 Apr 2012 09:06:05 +0000 (UTC) "Joseph S. Myers" <jos...@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
