cross-distro April 2012

cross-distro@lists.linaro.org

25 participants
9 discussions

[PATCH v2] ARM: Use different linker path for hardfloat ABI

by Michael Hope

Change the dynamic linker path for ARM hard float executables. Matches the path discussed and agreed on last week[1]. Carlos will follow up with the matching patch to GLIBC[2]. I'm happy to if he's busy. OK for trunk? -- Michael [1] http://sourceware.org/ml/libc-ports/2012-04/msg00060.html [2] http://sourceware.org/ml/libc-ports/2012-04/msg00064.html 2012-04-23 Michael Hope <michael.hope(a)linaro.org> * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define. (GLIBC_DYNAMIC_LINKER_SOFT_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..3ddf812 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. */

12 years

Armhf dynamic linker path

by Steve McIntyre

Hi folks, We really need to push on with getting the loader path for armhf standardised. The path that was agreed months ago is /lib/arm-linux-gnueabihf/ld-linux.so.3 but clearly not everybody is using that yet. Dann has just posted an updated patch for gcc, and we want to get this reviewed / fixed up / accepted ASAP. Then we may need to backport it to older gcc releases. This is *important* so that we can help vendors release binaries that work on any hard-float distribution. For people who have made binaries that still use the old, broken location /lib/ld-linux.so.3, we can put symlinks in place *for now* but in the longer term as many distros switch to multi-arch the symlink is not an acceptable solution. I'm working on a more complete spec document for armhf to help us with this kind of thing, but it's not going as smoothly as I'd hoped and I don't want to wait for that as a blocker on the linker path. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

12 years

arm softfp ABI vs hardfp in rpm world

by Adrian Schröter

Hi, I would like to propose a change in the rpm provides/requires handling of libs and binaries. Right now, we use on arm the architecture to distinguish between hard and soft fp abi. This results to the fact that armv7l is complete incompatible to armv7hl due to the rpm architecture compatibility list (is this true everywhere?) This is IMHO technical wrong. For example an rpm with a static build soft-fp binary should be installable on a hard-fp system. The kernel and the hardware does support it and it would just run. But furthermore this will make it also impossible later to have mixed systems. What I like to do on openSUSE-ARM is to go the same way as i686 vs. x86_64 world did go. Declare i686 backward compatible from x86_64, but to extent the provides and requires with an extension. So a hf binary will still require a hf lib. A patch for rpm which should do this is attached, but I have not tested it, I have to admit. The reason is that want to discuss it here first, because this has a big impact: It would suddenly make the old armv7hl rpms not compatible anymore with the new ones. So, I would like to here if you share my POV here in general. And secondly, if you see a chance at all to do this switch. I promise to take care to push such a patch to rpm upstream, if you want it. thanks adrian PS: I have not evaluated how the NEON VFP world fits in here. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de

12 years, 1 month

ARM hard-float linker path - consensus

by Steve McIntyre

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(a)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(a)canonical.com> and Michael Hope <michael.hope(a)linaro.org> 2012-04-13 Steve McIntyre <steve.mcintyre(a)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(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

12 years, 1 month

Linaro Connect Q2, Hong Kong, 28th May - 1st June

by Steve McIntyre

Hey folks, The next Connect event is in Hong Kong at the end of May. I'm going to propose another cross-distro discussion there as normally happens. There's still time for people to register and turn up in person if you'd like to come along and can get travel organised, otherwise I'll post the details here so that people can connect remotely too. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

12 years, 1 month

[PATCH] ARM: Use different linker path for hardfloat ABI

by dann frazier

This is an updated version of a patch Debian and Ubuntu are using to use an alternate linker path for hardfloat binaries. The difference with this one is that it covers the case where no float flag was passed in, defaulting to the softfloat path. 2012-03-29 dann frazier <dann.frazier(a)canonical.com> * config/arm/linux-elf.h: Use alternate linker path for hardfloat ABI Index: gcc/config/arm/linux-elf.h =================================================================== --- gcc/config/arm/linux-elf.h (revision 185708) +++ gcc/config/arm/linux-elf.h (working copy) @@ -59,14 +59,21 @@ #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc" -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3" +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3" #define LINUX_TARGET_LINK_SPEC "%{h*} \ %{static:-Bstatic} \ %{shared:-shared} \ %{symbolic:-Bsymbolic} \ %{rdynamic:-export-dynamic} \ - -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \ + %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \ + %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \ + %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \ + %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \ + %{!mfloat-abi: \ + %{!msoft-float: \ + %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \ -X \ %{mbig-endian:-EB} %{mlittle-endian:-EL}" \ SUBTARGET_EXTRA_LINK_SPEC

12 years, 1 month

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

by Michael Hope

On 4 April 2012 04:17, Andrew Haley <aph(a)redhat.com> wrote: > On 04/03/2012 05:09 PM, Richard Earnshaw wrote: >> On 03/04/12 12:01, Jakub Jelinek wrote: >>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote: >>>> If, so then there's only one way to sort out this mess. >>>> >>>> /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader >>>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader >>> >>> The above scheme is a Debianism which no other distro is using. >>> >>> Jakub >>> >> >> Not really, it's just a naming convention for where the config-specific >> dynamic loader lives. It doesn't affect where the remaining shared >> libraries live. >> >> The subdirectories could be called fred and jim and it would still work. >> The only thing required is that this part of the naming scheme be >> agreed amongst the distros. >> >> This looks to me like it's turning into a bike-shed painting excerise >> between the distros out there. That's really sad. > > I don't think we ever even had the discussion: Debian invented their > Debian-internal scheme for managing multiple ABIs. They have in the past > used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros. -- Michael [1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html

12 years, 1 month

Re: Wanted: superstar hacker to complete Mono port to armhf

by Hector Oron

Hello Jo, I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI. 2012/2/2 Jo Shields <directhex(a)apebox.org>: > Right now, Mono is available in Debian armhf. This is a hack - what > we're actually doing is building Mono as an armhf binary, but built to > emit soft VFP instructions and using calling conventions and ABI for > armel. This hack works well enough for pure cross-platform code (like > the C# compiler) to run, but dies in a heap for anything complex. > > This situation is a bit on the crappy side of crap. > > In order for Mono on armhf not to be a waste of time, a "true" port > needs to be completed. If I were to make a not-remotely-educated guess, > I'd say it needs about 550 lines of changes, primarily the addition of > code to emit the correct instructions feeling the correct registers in > mono/mini/mini-arm.c plus a couple of tweaks to related headers. > > Upstream have also indicated that they're happy to provide guidance and > pointers on how to implement this port, although they're unable to > provide the requisite code themselves. > > Sadly, unless someone in the community is able to step forward and > contribute here, it's only a matter of time before the armhf packages > are rightfully marked RC-buggy, and 100+ packages need to be axed from > armhf. This would make me sad. -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.

12 years, 1 month

ARM summit at Plumbers 2011

by Steve McIntyre

Hi folks, Following on from the founding of the cross-distro ARM mailing list, I'd like to propose an ARM summit at this year's Linux Plumbers conference [1]. I'm hoping for a slot on Thursday evening, but this remains to be confirmed at this point. We had some lively discussion about the state of ARM Linux distros at the Linaro Connect [2] event in Cambridge last week. It rapidly became clear that some of the topics we discussed deserve a wider audience, so we're suggesting a meetup at Plumbers for that bigger discussion. The initial proposed agenda is: * ARM hard-float + What is it and why does it matter? + How can distributions keep compatible (i.e. gcc triplet to describe the port)? * Adding support for ARM as an architecture to the Linux Standard Base (LSB) + Does it matter? + What's needed? * FHS - multi-arch coming soon, how do we proceed? * 3D support on ARM platforms + Open GL vs. GLES - which is appropriate? but I'm sure that other people will think of more issues they'd like to discuss. :-) If you wish to attend, please reply to the cross-distro list and let us know to expect you. Make sure you're registered to attend Plumbers Conf, and get your travel and accommodation organised ASAP. [1] http://www.linuxplumbersconf.org/2011/ [2] http://connect.linaro.org/ Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro April 2012