[OE-core] Fwd: ARM hard-float linker path - consensus

Khem Raj raj.khem at gmail.com
Fri Apr 13 19:58:09 UTC 2012


On Fri, Apr 13, 2012 at 12:50 PM, Denys Dmytriyenko <denis at denix.org> wrote:
> On Fri, Apr 13, 2012 at 11:11:02AM -0700, Khem Raj wrote:
>> FYI this will impact us in coming time. If someone has questions
>> please bring it up
>
> While it's a slightly unexpected outcome (/lib/ld-linux-armhf.so.3) it's still
> good to see some agreement here.
>
> Do we want to make the necessary toolchain changes right away, or wait for
> them to propagate from upstream?

I plan to propose do it post 1.2 yocto release

>
> --
> Denys
>
>
>> ---------- Forwarded message ----------
>> From: Steve McIntyre <steve.mcintyre at linaro.org>
>> Date: Fri, Apr 13, 2012 at 10:37 AM
>> Subject: ARM hard-float linker path - consensus
>> To: cross-distro at lists.linaro.org
>> Cc: libc-ports at sourceware.org, gcc-patches at gcc.gnu.org
>>
>>
>> Hi folks,
>>
>> As promised, here's minutes from the call we had this
>> afternoon. Spoiler: the result we've agreed is
>>
>>  /lib/ld-linux-armhf.so.3
>>
>> And here's a transcription of the minutes from
>>
>>  https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>> ========================================
>>
>> Meeting: 13th April 2012, 15:00 UTC
>>
>> Agenda
>> ------
>>
>>  * Debian/Ubuntu have so far built using /lib/arm-linux-gnueabihf/ld-linux.so.3
>>  * Some other distros (Fedora, OpenSUSE) are still using
>> /lib/ld-linux.so.3 option which matches the older soft-float ABI
>>  * Some people are proposing /libhf/ld-linux.so.3 or
>> /libhfp/ld-linux.so.3 (multilib)
>>  * Some people proposed /lib/ld-arm-linux-gnueabihf.so.3 (similar to
>> x86_64, libs still in /lib, from Michael Hope)
>>  * What should we do as a community?
>>
>> Present
>> -------
>>
>> Name               Affiliations
>>
>> Steve McIntyre     ARM, Debian, Linaro
>> Wookey             ARM, Debian, Linaro
>> Richard Earnshaw   ARM, gcc
>> Jeff Law           Fedora, Red Hat, gcc, glibc
>> Jon Masters        Fedora, Red Hat
>> Andrew Haley       Fedora, Red Hat, gcc
>> Andreas Jaeger     SUSE, openSUSE, glibc
>> Carlos O'Donnell   Mentor, gcc
>> Steve Langasek     Canonical, Ubuntu, Debian
>> Dann Frazier       Canonical, Ubuntu, Debian
>> Adam Conrad        Canonical, Ubuntu, Debian
>> Matthias Klose     Canonical, Ubuntu, Debian
>> Mike Frysinger     Gentoo
>> Dennis Gilmore     Fedora, Red Hat
>>
>> Discussion
>> ----------
>>
>> We started with a couple of questions up front to establish the
>> grounds for discussion:
>>
>>  * We believed that decision makers were present for all the important
>>   parties, i.e. all the arm hard-float distros, plus toolchain
>>   developers. This meant that a decision taken at the meeting could
>>   be implemented without needing further arguments/negotiations.
>>
>>  * All the people present understood the importance of cross-distro
>>   binary compatibility, and they all wanted it. This led to agreement
>>   that we needed to agree on a standard path for the runtime linker
>>   for ARM hard-float Linux binaries.
>>
>> Debian and Ubuntu had so far been using the "multi-arch" path of
>> /lib/arm-linux-gnueabihf/ld-linux.so.3. Fedora and OpenSUSE were thus
>> far using /lib/ld-linux.so.3, the same as the soft-float ABI. Others
>> had proposed alternative paths such as /libhf/ld-linux.so.3 or
>> /libhfp/ld-linux.so.3 (multilib) or
>> /lib/ld-arm-linux-gnueabihf.so.3. Discussion showed that none of these
>> were found to be universally acceptable.
>>
>> Two parties were likely to be soon affected by an agreement here:
>>
>> 1. Ubuntu 12.04 (releasing with armhf in ~2 weeks)
>>
>> Adam/Steve L agreed that all efforts would be put in to switch the
>> compilers in Ubuntu to a new path before release. Default things like
>> gcc would be correct, but less common tools might still be targetting
>> the old path /lib/arm-linux-gnueabihf/ld-linux.so. at release. They
>> could be fixed in the longer term and would not stop progress here.
>>
>> 2. Mentor (Codebench due for release in ~1 week)
>>
>> Carlos mentioned this - Codebench has been using /lib/ld-linux.so.3
>> for hard-float binaries for some time and it was too late to change
>> that for this upcoming release. Next release due in October. Suggested
>> and accepted that this should be mentioned in release notes: if people
>> want to use Codebench on some systems (Debian/Ubuntu and derivatives),
>> they'll need to tweak their system setup. He may be able to do the
>> linker change and rebuild in a point release in a few weeks.
>>
>> It was briefly suggested that the soft-float linker should be renamed
>> away from /lib/ld-linux.so.3 as well at this time, but that idea was
>> quickly shot down.
>>
>> Proposal #1: /lib/ld-armhf.so.3       (not generally liked)
>>
>> Proposal #2: /lib/ld-linux-armhf.so.3 (not favourite, but considered
>>                                       an acceptable compromise by all)
>>
>> No need to go any further.
>>
>> Conclusion
>> ----------
>>
>> All the people in the meeting agreed: the new runtime linker path for
>> ARM hard-float Linux binaries was to be
>>
>> /lib/ld-linux-armhf.so.3
>>
>> ACTION: People at the meeting to present this decision to their
>>        companies / communities and get the appropriate changes made.
>>
>> Further discussion
>> ------------------
>>
>> General unhappiness with the mess that led to this meeting. Future
>> planning needs to be better between the various groups for the next
>> time we have a new CPU/ABI/whatever.
>>
>> ACTION: Jon Masters to talk to the Linux Foundation about setting up a
>>        forum for such discussions.
>>
>> In the meantime, strong consensus to use the
>> cross-distro at lists.linaro.org mailing list for any more conversations
>> now we have people in contact.
>>
>> ACTION: Steve McIntyre to write up the minutes and circulate. Include
>>        an updated linker path patch for gcc to match the decision
>>        made here.
>>
>> More discussion about triplets and naming, but nothing came of it in
>> the end. Distro folks have already decided what they're using and have
>> patched various software to build appropriately. Richard wants to move
>> gcc's config.guess to use arm-linux-gnueabihf; no strong objections to
>> that.
>>
>> Linker path patch for gcc
>> -------------------------
>>
>> Adapted from earlier work by Dann Frazier <dann.frazier at canonical.com>
>> and Michael Hope <michael.hope at linaro.org>
>>
>> 2012-04-13 Steve McIntyre <steve.mcintyre at linaro.org>
>>
>>       * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
>>       (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
>>
>> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
>> index 80bd825..8c9d2e7 100644
>> --- a/gcc/config/arm/linux-eabi.h
>> +++ b/gcc/config/arm/linux-eabi.h
>> @@ -62,7 +62,11 @@
>>  /* Use ld-linux.so.3 so that it will be possible to run "classic"
>>    GNU/Linux binaries on an EABI system.  */
>>  #undef  GLIBC_DYNAMIC_LINKER
>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
>> +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
>> +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT "/lib/ld-linux-armhf.so.3"
>> +#define GLIBC_DYNAMIC_LINKER \
>> +   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
>>
>>  /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
>>    use the GNU/Linux version, not the generic BPABI version.  */
>>
>>
>> Post-meeting on IRC
>> -------------------
>>
>> Suggested that Richard should push the change into gcc trunk
>> ASAP. Steve McIntyre agreed to work on that with Richard.
>>
>> Also suggested that we want to get a patch into glibc too to change
>> the installation path for ARM hard-float. Andrew agreed to push glibc
>> upstream for that.
>>
>> Cheers,
>> --
>> Steve McIntyre                                steve.mcintyre at linaro.org
>> <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




More information about the Openembedded-core mailing list