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.

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

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 

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

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

Joseph S. Myers

Reply via email to