On 4 April 2012 10:56, Joseph S. Myers <jos...@codesourcery.com> wrote:
> On Tue, 3 Apr 2012, Michael Hope wrote:
>> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
> (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
> be handled in specs.


> (b) You need to handle compilers configured with --with-float=hard, so
> make the specs depend on the default ABI the compiler was configured with.

GCC seems to take configure time options into account when evaluating
a spec file.

Tested by building a default, --with-float=hard, and
--with-float=softfp compiler then checking the loader path for all
combinations of {,-mglibc,-mbionic,-muclibc} x

> (c) Please include libc-ports on future submissions and provide both the
> GCC patch and the glibc ports patch that have been tested to work together
> to build and install the library in the given path; a patch to one
> component like this cannot sensibly be considered in isolation.  I imagine
> you'll need appropriate ARM preconfigure support to detect what ABI the
> compiler is using, much like the support for MIPS, so that the right
> shlib-versions files are used.


>  I try to follow all ARM glibc discussions
> on libc-ports closely, as the ARM glibc maintainer; was there a previous
> discussion of the dynamic linker naming issue there that I missed?

Steve McIntyre is driving this inside Debian.  I'll ping him on the
GLIBC support.

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.

>  (The only previous relevant discussion that I recall is one on
> patc...@eglibc.org starting at
> <http://www.eglibc.org/archives/patches/msg01017.html>, regarding how the
> dynamic linker should check that a library has the right ABI, and there
> was no real followup on that after I indicated what would seem to be the
> appropriate implementation approaches and places for subsequent
> discussion.)

The patch above changes the loader to catch a mixed installation and
reject mixing incompatible libraries.  The static linker does this
currently but it's not essential.

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

> (d) Existing practice for Power Architecture and MIPS at least is that
> hard-float and soft-float *don't* use different library directories /
> dynamic linkers.

The goal is to have a standard loader path for all hard float distros
and, similar to how you can have a mixed 32/64 bit installation, allow
mixed softfp/hard float installations for distros that want it.  This
is a new requirement and ARM is the first one exposed to it.  I assume
Debian would push for similar changes on MIPS and PowerPC.

Do the MIPS or PowerPC loaders detect the ABI and change the library
path based on that?  I couldn't tell from the code.

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

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

> 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

(BTW Dann, apologies for stealing your patch)

-- Michael

2012-04-03  Michael Hope  <michael.h...@linaro.org>

       * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
       (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.

diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8c9d2e7 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
 /* Use ld-linux.so.3 so that it will be possible to run "classic"
    GNU/Linux binaries on an EABI system.  */
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+    %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
    use the GNU/Linux version, not the generic BPABI version.  */

Reply via email to