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)


Reply via email to