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
> > 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
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
Joseph S. Myers