On Wed, Apr 04, 2012 at 02:39:58PM +1200, Michael Hope wrote:
On 4 April 2012 10:56, Joseph S. Myers joseph@codesourcery.com wrote:
On Tue, 3 Apr 2012, Michael Hope wrote:
+#define GLIBC_DYNAMIC_LINKER \
- "%{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.
Fixed.
(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 {,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.
(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.
Agreed.
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 patches@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 resemblance.
(BTW Dann, apologies for stealing your patch)
s/stealing/improving upon/ :)
No worries, it is appreciated.
-- Michael
2012-04-03 Michael Hope michael.hope@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. */ #undef GLIBC_DYNAMIC_LINKER -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/arm-linux-gnueabihf/ld-linux.so.3" +#define GLIBC_DYNAMIC_LINKER \
- "%{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. */