This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Phone call (was Re: Armhf dynamic linker path)
- From: Michael Hope <michael dot hope at linaro dot org>
- To: Steve McIntyre <steve dot mcintyre at linaro dot org>
- Cc: cross-distro at lists dot linaro dot org, gcc-patches at gcc dot gnu dot org, Adam Conrad <adconrad at debian dot org>, libc-ports at sourceware dot org, linaro-toolchain at lists dot linaro dot org, Jeff Law <law at redhat dot com>
- Date: Thu, 12 Apr 2012 11:22:13 +1200
- Subject: Re: Phone call (was Re: Armhf dynamic linker path)
- References: <20120331103406.GA17776@einval.com> <201204100019.13472.vapier@gentoo.org> <4F83B5AD.3010302@redhat.com> <201204100033.08853.vapier@gentoo.org> <4F83B939.10205@redhat.com> <4F84AC96.6020500@redhat.com> <20120411010608.GC25263@einval.com> <20120411223755.GD25263@einval.com>
On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote:
> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>
>>And here's the details as promised.
>>
>>I've started a wiki page at
>>
>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>>with a strawman agenda for now, and a Doodle poll at
>>
>>http://www.doodle.com/93bitkqeb7auyxn7
>>
>>to see when the best time is for the call on Thursday/Friday. Please
>>fill in the times that work for you ASAP and I'll announce the result
>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>distros and the upstream toolchain developers to be there, able to
>>represent their groups and (importantly) able to make a decision here
>>on what we should do.
>>
>>Apologies for the short notice, but we need a decision quickly.
>
> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
> person who can't make that time is Michael in .nz. Sorry, Michael.
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
* is similar to /lib/ld-x86-64.so.2
* keeps the libraries and loader in the same directory
* doesn't invent a new /libhf directory
* is easier to implement in GLIBC
* is architecture and ABI unique
* requires less change for distros where the hard float libraries are
already in /lib
I'm happy to do the GLIBC and GCC implementation.
-- Michael