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)
Em 11 de abril de 2012 22:39, Michael Hope <michael.hope@linaro.org> escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade@gmail.com>:
>> Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu:
>>> 2012/4/12 Paulo César Pereira de Andrade
>>> <paulo.cesar.pereira.de.andrade@gmail.com>:
>>>> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu:
>>>>> 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
>>>>
>>>> ?Sorry for more bikeshedding, but afaik rpm based distros are
>>>> using the armv7hl identifier, so it could as well be
>>>>
>>>> /lib/ld-linux-armv7hl.so.3
>>>
>>> This includes the ABI (h), adds the endianess (l), and implies a
>>> architecture level (v7). ?The name for the most common configurations
>>> should be as short as possible so I'd rather drop the 'l' and add a
>>> 'b' or 'eb' if anyone wants a big endian distro in the future. ?The
>>> architecture level is a problem as the loader should also be valid on
>>> ARMv5 and ARMv6 hard float builds. ?Skype should be able to make a
>>> hard float binary that runs on everything, including a potential ARMv6
>>> hard float RaspberryPi build.
>>
>> ?This means ld.so (and what else? a skype binary should not come fully
>> statically linked) should be built with -march=armv5te? That is, common
>> denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
>> ?AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
>> that has a div instruction in thumb mode).
>
> The architecture and feature set is a different topic and should be
> discussed by the distros but I'd rather finish the loader path one
> first. ?Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have
> all taken the opportunity to go to ARMv7 at the same time as switching
> to hard float.
Ok. It obviously should be up to distros if they want the hardfp packages
to be able to run on armv5 with a vfp :-) And so is for skype if they want
it to run on such distro if it exists. Simpler alternate name would be
/lib/ld-linux-armh.so.3
> -- Michael
Paulo