This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
- From: Steve McIntyre <steve dot mcintyre at linaro dot org>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: cross-distro at lists dot linaro dot org, Richard Earnshaw <rearnsha at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, libc-ports at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 5 Apr 2012 17:15:41 +0100
- Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI
- References: <20120329193401.GA14860@dannf.org> <20120404070946.071e7c45@pegasus.ausil.us> <20120405163023.561469dca6619e31cf7a1d9e@linaro.org> <201204051108.58683.vapier@gentoo.org>
On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
>On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
>> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote:
>> > 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
>>
>> One potential problem that is born from the /libhf suggestion is the
>> danger of having a new top level directory (/libhf) with only one file,
>> the dynamic linker. AFAIU it, no distro is currently willing to move away
>> from its existing scheme (/lib)
>
>i don't think that's true. on an x86_64 system, the 64bit libs are in
>/lib64/. some distros tried to (pointlessly imo) resist and force 64bits into
>/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy
>imo, and afaik, they didn't break the ldso paths.
>
>so in a setup that only has hardfloat binaries, you'd have all the libs in
>/libhf/, not just the ldso.
>
>> Loic suggested a -IMHO- better solution: to change the dynamic linker
>> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
>> case).
>
>the implication in supporting both hardfloat and softfloat simultaneously is
>that you'd could have them both installed. thus putting them both in /lib/
>doesn't make much sense if you're still going to need /libhf/ to hold
>everything else.
Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
them all in cleanly-separated paths corresponding to the triplets.
I'm concerned that the potential proliferation of /lib* directories
here could become very messy over time. I'm surprised that people seem
to be happy to invent another namespace on a much more ad-hoc and
arbitrary basis than the (mostly) well-understood triplets that we
already have defined in the toolchains.
Multi-arch is an attempt to make things cleaner for those of us that
care about having lots of different platforms supported in
parallel. Seen against that background, I was hoping that using the
multi-arch path for the armhf linker would make sense. For people that
don't care about multi-arch for themselves, a simple symbolic link is
all that's needed.
Cheers,
--
Steve McIntyre steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs