Re: [PATCH] ARM: Use different linker path for hardfloat ABI

["Joseph S. Myers" <joseph at codesourcery dot com>]

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).

-- 
Joseph S. Myers
joseph@codesourcery.com