Em 11 de abril de 2012 22:39, Michael Hope <michael.h...@linaro.org> escreveu: > 2012/4/12 Paulo César Pereira de Andrade > <paulo.cesar.pereira.de.andr...@gmail.com>: >> Em 11 de abril de 2012 21:16, Michael Hope <michael.h...@linaro.org> >> escreveu: >>> 2012/4/12 Paulo César Pereira de Andrade >>> <paulo.cesar.pereira.de.andr...@gmail.com>: >>>> Em 11 de abril de 2012 20:22, Michael Hope <michael.h...@linaro.org> >>>> escreveu: >>>>> On 12 April 2012 10:38, Steve McIntyre <steve.mcint...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
