This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at systemhalted dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Carlos O'Donell <carlos_odonell at mentor dot com>, Andrew Haley <aph at redhat dot com>, libc-ports at sourceware dot org, steve dot mcintyre at linaro dot org, michael dot hope at linaro dot org
- Date: Sat, 5 May 2012 21:47:49 +0000 (UTC)
- Subject: Re: [WIP] glibc: Use /lib/ld-linux-armhf.so.3 for ARM's -mfloat-abi=hard ABI.
- References: <4F886201.3040200@redhat.com> <4F886277.6000006@redhat.com> <20120413173512.5D52B2C074@topped-with-meat.com> <CADZpyiyr3d8VrBwp_WQyg1H_=w-8hyHw82Vck6U2kv49JtFxPg@mail.gmail.com> <4F9515D5.60804@redhat.com> <4F99B990.7020300@mentor.com> <Pine.LNX.4.64.1204262155510.30855@digraph.polyomino.org.uk> <20120426220656.0CC302C0D3@topped-with-meat.com> <CADZpyiw=iR9DURWUwY81FS-miA+gFNQdsK7Fkgo_GJAPzJ11+g@mail.gmail.com>
On Sat, 5 May 2012, Carlos O'Donell wrote:
> +# The EABI-derived hard-float ABI uses a new dynamic linker.
> +arm.*-.*-linux-gnueabihf ld=ld-linux-armhf.so.3
That bit's not needed, because the compiler will define __ARM_PCS_VFP.
> +# The legacy ABI, no longer supported, uses ld-linux.so.2.
> arm.*-.*-linux.* ld=ld-linux.so.2
And that is no longer in the current shlib-versions, as old-ABI support
has been removed.
> I'm not happy with this patch. I don't like it for the reason that an
> old unpatched gcc that still uses /lib/ld-linux.so.3 with a new glibc
> produces a glibc with /lib/ld-linux-armhf.so.3 even if the compiler
> doesn't. I guess in this case your setup is completely broken and
> testing should show you that.
>
> Is it important to support the old gcc + new glibc for the hardfloat use case?
I don't see it as important. Given the dynamic linker name change, to
build / use new glibc you will need to patch your compiler to match if it
predates the change. Since we've agreed the ABI change, glibc shouldn't
try to build for the old incompatible dynamic linker name any more; at
most there could be detection of unpatched compilers to give an obvious
error, but I think that's too complicated (given that configure tests
requiring a previously built libc are to be avoided) to be worthwhile.
--
Joseph S. Myers
joseph@codesourcery.com