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,
On Sat, 31 Mar 2012 11:34:13 +0100 Steve McIntyre steve.mcintyre@linaro.org wrote:
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,
I can say for Fedora that we have no plans to adopt that change. AFAIK we never agreed to do so infact this is the first ive heard of it, we have moved everything from /bin /lib /lib64 to under /usr in Fedora 17. we do have symlinks to the original locations.
we use a host triplet of redhat-linux-gnu everywhere, we have special handling in gcc and glibc to set it to redhat-linux-gnueabi for those two builds we also set the arch portion to the target arch so it is one of armv7hnl-redhat-linux-gnu or armv5tel-redhat-linux-gnu its done that way to maintain compatability with all our other arches we use armhfp as the base arch for floating point in Fedora. at this point we support armv7hl as the base arch and armv7hnl as a sub arch for neon optimised things though really neon iwmmx etc should all be run time detectable. I really dont see the linker path being set as proposed as working for us any time soon. its not to say that we cant change things in the future. but its not been proposed or even thought of since awareness at this point is nill.
I have no idea how linaro actually works or engages the community because ive never seen it do so. I suggest if you really want to change something on all distros you need to reach out and engage them. Im not trying to inflame or otherwise start any kind of argument. Im want to make sure we engage in a positive discussion. I really have no idea how this was planned or where it was discussed or anything about it. If the goal is to effect change within distros, the distros need to be fully engaged.
This needs to be a two way street. From my perspective there are many things that need to be fixed to making supporting arm by distros scale better, they are problems that need to be fixed at higher levels than the distros. I will work to find where to engage people to get them worked on.
Regards
Dennis
On 03/31/2012 10:42 AM, Dennis Gilmore wrote:
I can say for Fedora that we have no plans to adopt that change. AFAIK we never agreed to do so infact this is the first ive heard of it, we have moved everything from /bin /lib /lib64 to under /usr in Fedora 17. we do have symlinks to the original locations.
Dennis,
For context, we have discussed this several times at Linaro Connect and other events, and I've talked it through with Jeff Law and others. What we agreed to at the time (and in other conversations) was that following an upstream proposal for a linker prefix change, then we'd look at it. I know a number of baseos types on the Fedora end actually like the idea. So, it would be unfair to say it hasn't been thought about, but it's not been put out to FESCo, etc. because this is something that needs to fix changed upstream before Fedora.
Jon.
On 03/31/2012 12:04 PM, Jon Masters wrote:
On 03/31/2012 10:42 AM, Dennis Gilmore wrote:
I can say for Fedora that we have no plans to adopt that change. AFAIK we never agreed to do so infact this is the first ive heard of it, we have moved everything from /bin /lib /lib64 to under /usr in Fedora 17. we do have symlinks to the original locations.
For context, we have discussed this several times at Linaro Connect and other events, and I've talked it through with Jeff Law and others. What we agreed to at the time (and in other conversations) was that following an upstream proposal for a linker prefix change, then we'd look at it. I know a number of baseos types on the Fedora end actually like the idea. So, it would be unfair to say it hasn't been thought about, but it's not been put out to FESCo, etc. because this is something that needs to fix changed upstream before Fedora.
So they're doing the right thing here in proposing stuff upstream. That's the long and the short of it. I suggest we allow that to happen, and some of us who think it's a good idea can express enthusiasm for those patches. Then, once there is an upstream solution, we can come back to the Fedora community and suggest some changes more broadly. This didn't happen in a vacuum (honest), but we knew that nobody in Fedora would be interested in a non-upstream viable solution.
This is another reason why v8 will not be allowed to repeat the same mistakes. None of us in any of the distros should adopt any v8 release until we have agreed on the path to the frigging linker. That's just plain crazy. I note that I was up late reading the prelink sources and I'm also wondering (totally unrelated) how much fun that will be :)
Jon.
On Sat, 31 Mar 2012 12:04:20 -0400 Jon Masters jonathan@jonmasters.org wrote:
On 03/31/2012 10:42 AM, Dennis Gilmore wrote:
I can say for Fedora that we have no plans to adopt that change. AFAIK we never agreed to do so infact this is the first ive heard of it, we have moved everything from /bin /lib /lib64 to under /usr in Fedora 17. we do have symlinks to the original locations.
Dennis,
For context, we have discussed this several times at Linaro Connect and other events, and I've talked it through with Jeff Law and others. What we agreed to at the time (and in other conversations) was that following an upstream proposal for a linker prefix change, then we'd look at it. I know a number of baseos types on the Fedora end actually like the idea. So, it would be unfair to say it hasn't been thought about, but it's not been put out to FESCo, etc. because this is something that needs to fix changed upstream before Fedora.
Jon.
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic. I guess i need to go find and read the existing documents on what exactly is proposed and how it is intended to work. Its not been thought about in the wider community, I suspect its not been thought about in other distros also. I am open to being wrong.
Dennis
On 03/31/2012 12:52 PM, Dennis Gilmore wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made.
So the purpose of discussing it there was twofold:
1). To debate what the preferred single unified path would be - it's ARM specific, it makes sense to do it somewhere :)
2). To push back about the need for an upstream strategy. I spoke with a number of folks on our end discretely about this, and in the interest of not being burned, everyone said it needed to be proposed upstream before we'd consider touching it.
At the same time, I think I'd like to apologize for any failure on my part here. I want cross-distribution harmony and co-ordination, but we live in a world fraught with politics and distrust between different Linux players. So, I approach this with much caution having been burned in the past with what seemed like reasonable ambitions. I'll go out and buy some new asbestos pants and try a more direct approach next time.
Jon.
Hi Dennis,
On 31 March 2012 19:52, Dennis Gilmore dennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
Wide community engagement is a specter, something that escapes no matter how hard you try to reach it. But that doesn't mean we shouldn't try harder. For a starter, what community channels do you follow? If fedora wanted to change the linker path and you wanted to ensure all other distros remain compatible, which avenues would you reach for?
[1] http://www.linuxplumbersconf.org/2011/ocw/sessions/783
This needs to be a two way street. From my perspective there are many things that need to be fixed to making supporting arm by distros scale better, they are problems that need to be fixed at higher levels than the distros. I will work to find where to engage people to get them worked on.
That is why this linaro cross-distro mailing list was created. Unfortunately it hasn't generated lots of involvment yet (apart from the . Of course not everyone is aware of it, and there is a limit on how much can advertise before we are blamed as spammers. But also most distros appear to prefer to work within them self instead of in a wider community.
Riku
On Mon, Apr 2, 2012 at 09:19, Riku Voipio riku.voipio@linaro.org wrote:
On 31 March 2012 19:52, Dennis Gilmore dennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline. -mike
On 04/02/2012 03:04 PM, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 09:19, Riku Voipio riku.voipio@linaro.org wrote:
On 31 March 2012 19:52, Dennis Gilmore dennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
Right. For clarification, we (Fedora) have no plans to do multi-arch (though I know many of us are personally interested in the idea). That doesn't mean we can't have a platform specific linker path change.
Again, AArch64 needs to be perfection from day 1. There will be no changing of linker paths or other nonsense after we ship something.
Jon.
On 02.04.2012 21:46, Jon Masters wrote:
On 04/02/2012 03:04 PM, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 09:19, Riku Voipioriku.voipio@linaro.org wrote:
On 31 March 2012 19:52, Dennis Gilmoredennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
Right. For clarification, we (Fedora) have no plans to do multi-arch (though I know many of us are personally interested in the idea). That doesn't mean we can't have a platform specific linker path change.
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location. I am a bit surprised that this comes up again, and I really would like to settle this within the next two weeks. Note that Ubuntu 11.10 already did ship with this ldso name based on these discussions. Jon, afaicr I did ask this very same question (if the ldso name in a multiarch location would be acceptable) at Linaro Connect in August 2011 in Cambridge, and afaicr you didn't object to this path.
thanks, Matthias
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
On 02.04.2012 21:46, Jon Masters wrote:
On 04/02/2012 03:04 PM, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 09:19, Riku Voipioriku.voipio@linaro.org wrote:
On 31 March 2012 19:52, Dennis Gilmoredennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
Right. For clarification, we (Fedora) have no plans to do multi-arch (though I know many of us are personally interested in the idea). That doesn't mean we can't have a platform specific linker path change.
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
in the last patch it seemed like only the path differed, but the ldso was still named "ld-linux.so.3", but maybe i misread it and/or confused it with an old patch. the new HF ldso will always be "ld-linux.so.3" while the old who-knows-what-ABI-it-actually-is name will be "ld-linux.so.2" ?
I am a bit surprised that this comes up again, and I really would like to settle this within the next two weeks. Note that Ubuntu 11.10 already did ship with this ldso name based on these discussions. Jon, afaicr I did ask this very same question (if the ldso name in a multiarch location would be acceptable) at Linaro Connect in August 2011 in Cambridge, and afaicr you didn't object to this path.
i've never attended a conference in Cambridge (US or UK). maybe you're remembering something else ? -mike
On Mon, Apr 02, 2012 at 07:56:16PM -0400, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
On 02.04.2012 21:46, Jon Masters wrote:
On 04/02/2012 03:04 PM, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 09:19, Riku Voipioriku.voipio@linaro.org wrote:
On 31 March 2012 19:52, Dennis Gilmoredennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
Right. For clarification, we (Fedora) have no plans to do multi-arch (though I know many of us are personally interested in the idea). That doesn't mean we can't have a platform specific linker path change.
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
in the last patch it seemed like only the path differed, but the ldso was still named "ld-linux.so.3",
That's correct.
but maybe i misread it and/or confused it with an old patch. the new HF ldso will always be "ld-linux.so.3" while the old who-knows-what-ABI-it-actually-is name will be "ld-linux.so.2" ?
The intent of this patch is to continue to use /lib/ld-linux.so.3[*] for ARM EABI (aka "softfloat"/armel), but switch to /lib/arm-linux-gnueabihf/ld-linux.so.3 for the hard float variant. This allows for concurrent support of both ABIs on the same install.
/lib/ld-linux.so.2, as I understand it, is the legacy ABI (OABI). My updated patch preserves this support.
-dann
[*] The /lib/ld-linux.so.3 bit isn't visible in my latest patch because it is specified in a different file.
I am a bit surprised that this comes up again, and I really would like to settle this within the next two weeks. Note that Ubuntu 11.10 already did ship with this ldso name based on these discussions. Jon, afaicr I did ask this very same question (if the ldso name in a multiarch location would be acceptable) at Linaro Connect in August 2011 in Cambridge, and afaicr you didn't object to this path.
i've never attended a conference in Cambridge (US or UK). maybe you're remembering something else ? -mike
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 3 April 2012 02:56, Mike Frysinger vapier@gentoo.org wrote:
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
For some value of "mainline standard":
https://wiki.linaro.org/RikuVoipio/LdSoTable
Quite clear there has been no effort in naming except in the few cases "something" was hacked in to allow coinstall of 64bit binaries.
The choice of using multiarch path for armhf linker path was agreed mostly because 1) people agreed that having the possibility of armhf and armel binaries on the same systems is useful and 2) nobody proposed anything else.
Riku
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
On 3 April 2012 02:56, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
For some value of "mainline standard":
https://wiki.linaro.org/RikuVoipio/LdSoTable
Quite clear there has been no effort in naming except in the few cases "something" was hacked in to allow coinstall of 64bit binaries.
we all agree arm's current situation is f-ed. however, i don't agree with your analysis of any of the other targets. they all look sane to me.
The choice of using multiarch path for armhf linker path was agreed mostly because 1) people agreed that having the possibility of armhf and armel binaries on the same systems is useful and 2) nobody proposed anything else.
i don't see value in having multiple endians being active simultaneously. it might make for a fun exercise, but people won't deploy systems with them both installed. after all, the kernel isn't bi-endian on the fly. -mike
On Wed, Apr 04, 2012 at 09:18:13PM -0400, Mike Frysinger wrote:
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
On 3 April 2012 02:56, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
For some value of "mainline standard":
https://wiki.linaro.org/RikuVoipio/LdSoTable
Quite clear there has been no effort in naming except in the few cases "something" was hacked in to allow coinstall of 64bit binaries.
we all agree arm's current situation is f-ed. however, i don't agree with your analysis of any of the other targets. they all look sane to me.
The choice of using multiarch path for armhf linker path was agreed mostly because 1) people agreed that having the possibility of armhf and armel binaries on the same systems is useful and 2) nobody proposed anything else.
i don't see value in having multiple endians being active simultaneously. it might make for a fun exercise, but people won't deploy systems with them both installed. after all, the kernel isn't bi-endian on the fly. -mike
Do you mean multiple ABIs? The kernel does support both EABI (Debian's armel) and EABI/Hardfloat (Debian's armhf) concurrently, and there are realworld reasons you'd want to do it (e.g. closed armel Xorg drivers, but an otherwise armhf-optimized system).
-dann
On Wednesday 04 April 2012 21:31:20 dann frazier wrote:
On Wed, Apr 04, 2012 at 09:18:13PM -0400, Mike Frysinger wrote:
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
On 3 April 2012 02:56, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote:
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
The choice of using multiarch path for armhf linker path was agreed mostly because 1) people agreed that having the possibility of armhf and armel binaries on the same systems is useful and 2) nobody proposed anything else.
i don't see value in having multiple endians being active simultaneously. it might make for a fun exercise, but people won't deploy systems with them both installed. after all, the kernel isn't bi-endian on the fly.
Do you mean multiple ABIs?
no -- i said "endian" here a few times. i agree that multiple ABIs makes sense. (let's not pointlessly nitpick endian encoding as part of the ABI and just go with what people more commonly use.)
The kernel does support both EABI (Debian's armel) and EABI/Hardfloat (Debian's armhf) concurrently
too bad the OABI shim is buggy :( -mike
On 5 April 2012 04:18, Mike Frysinger vapier@gentoo.org wrote:
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
The choice of using multiarch path for armhf linker path was agreed mostly because 1) people agreed that having the possibility of armhf and armel binaries on the same systems is useful and 2) nobody proposed anything else.
i don't see value in having multiple endians being active simultaneously. it might make for a fun exercise, but people won't deploy systems with them both installed. after all, the kernel isn't bi-endian on the fly.
Sorry for being ambigous. With "armel" I mean arm eabi with softfloat abi. What people agreed was useful was supporting those binaries along with eabi hardfloat binaries "armhf". Both are in this case little-endian. I'm not aware of anyone interested in different endian binaries on same systems.
Riku
On Thursday 05 April 2012 05:06:43 Riku Voipio wrote:
On 5 April 2012 04:18, Mike Frysinger wrote:
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote:
The choice of using multiarch path for armhf linker path was agreed mostly because 1) people agreed that having the possibility of armhf and armel binaries on the same systems is useful and 2) nobody proposed anything else.
i don't see value in having multiple endians being active simultaneously. it might make for a fun exercise, but people won't deploy systems with them both installed. after all, the kernel isn't bi-endian on the fly.
Sorry for being ambigous. With "armel" I mean arm eabi with softfloat abi. What people agreed was useful was supporting those binaries along with eabi hardfloat binaries "armhf".
sure, we all agree on that :) -mike
+++ Mike Frysinger [2012-04-02 19:56 -0400]:
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
Right. For clarification, we (Fedora) have no plans to do multi-arch (though I know many of us are personally interested in the idea). That doesn't mean we can't have a platform specific linker path change.
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
It isn't helpful to think about this as a 'multiarch' thing. It's about having a unique linker path everyone uses for a particular ABI so that binaries can be run on more than one distro.
The use of a GNU triplet to distinguish the 'armhf' ABI linker path is just a sensible way to do it (and it'll work for future arches/ABIs too). That brings no multiarchness at all with it.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
No-one can 'deal' with the fact that you can't have binaries of different ABIs work in the same filesystem unless they have unique linker paths. And if we want 3rd-party-shipped binaries to work on (say, Redhat and Debian and Ubuntu and Fedora (which we do), those distros need to be using the same linker path).
So that requires a path that is unique across ABIs and common across distros.
Riku has helpfully documented the current state here.
I am a bit surprised that this comes up again, and I really would like to settle this within the next two weeks. Note that Ubuntu 11.10 already did ship with this ldso name based on these discussions. Jon, afaicr I did ask this very same question (if the ldso name in a multiarch location would be acceptable) at Linaro Connect in August 2011 in Cambridge, and afaicr you didn't object to this path.
i've never attended a conference in Cambridge (US or UK). maybe you're remembering something else ?
He said 'Jon' and was talking about Jon masters
Wookey
On Wednesday 04 April 2012 22:48:34 Wookey wrote:
Mike Frysinger [2012-04-02 19:56 -0400]:
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
Right. For clarification, we (Fedora) have no plans to do multi-arch (though I know many of us are personally interested in the idea). That doesn't mean we can't have a platform specific linker path change.
yes, this was brought up at Linaro Connect as well; having the ldso name in a multiarch location doesn't mean that anything else needs to be in this location.
while true, it seems like /lib/<ldso> vs /lib/<multiarch>/<ldso> needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs.
It isn't helpful to think about this as a 'multiarch' thing. It's about having a unique linker path everyone uses for a particular ABI so that binaries can be run on more than one distro.
The use of a GNU triplet to distinguish the 'armhf' ABI linker path is just a sensible way to do it (and it'll work for future arches/ABIs too). That brings no multiarchness at all with it.
trying to paint the use of a triplet in the path as any other than multiarch is bunk. as Joseph explained in detail, there already is a standard in mainline tools. if you want to change the standard, then propose something consistently for everyone. backdooring it for 1 target is not the way.
i know it's a bit of bike shedding, but if the mainline standard is /lib/<ldso> and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/<ldso>.
No-one can 'deal' with the fact that you can't have binaries of different ABIs work in the same filesystem unless they have unique linker paths. And if we want 3rd-party-shipped binaries to work on (say, Redhat and Debian and Ubuntu and Fedora (which we do), those distros need to be using the same linker path).
So that requires a path that is unique across ABIs and common across distros.
everyone has already agreed that we should have a new unique ldso name for armv7/hardfloat. so you're not really stating anything new here. -mike
On Wed, Apr 04, 2012 at 11:11:30PM -0400, Mike Frysinger wrote:
On Wednesday 04 April 2012 22:48:34 Wookey wrote:
Mike Frysinger [2012-04-02 19:56 -0400]:
trying to paint the use of a triplet in the path as any other than multiarch is bunk. as Joseph explained in detail, there already is a standard in mainline tools. if you want to change the standard, then propose something consistently for everyone. backdooring it for 1 target is not the way.
It's not readily changable for all targets, and you know that (or, at least, I hope you know that?). As Jeff Law said at Plumbers (where there were Gentoo people sitting in as well, whose opinion was "Gentoo doesn't care, do whatever), "This is something we should have been doing for the last twenty years".
I appreciate that it's irksome to have to deal with Debian's terrible and unreasonable desire to install more than one base architecture at the same time, but while you accuse us of "backdooring" (we intentionally brough people together to discuss this, repeatedly), are you not just as much hindering Debian over nothing more than a path to a single file?
To be very, very, very clea here. multilib can not solve the "different base arches on one system problem". lib/lib32/lib64/libhf/libsf will overlap as soon as you have more than one of x86, arm, power, mips, etc.
To be extra clear, we're NOT asking people to implement multiarch. We'd like that to happen some day, but this isn't some "slippery slope", this is the path to ONE file. One. In Debian, we currently have that path (for, say, x86_64) in locations we'd no prefer. We don't argue with the world that it's ugly, we just place the linker where everyone else does.
In the armhf case, given that very few of us were shipping armhf, and only some of us had really bootstrapped an archive worth talking about, we felt that we could discuss this last year and reach a consensus. And we did. At least, we did until it got bikeshedded to death more than six months later.
I'll agree with you that Debian's multiarch doesn't account for every possible ABI, as it only accounts for (oddly enough), the ones that they ship. This could be fixed.
I'll also agree that having the linker in an ABI-unqiue (including arch-unique, which multilib CAN NOT provide) path would be ideal, though we all know that i386 and x86_64 will probably end up carrying compat symlinks for years to deal with all the commercial software. Thankfully, most non-x86 ports could actually just hard-switch and carry on with it.
Again (and again, and again), this isn't about Debian trying to push multi- arch on people, it's about having a linker path that works for everyone. The proposed /lib/(arbitrary-unique-name)/ld-linux make it work for everyone, but some say it's "ugly" or "unsightly", or downright backdoorish. The proposed "keep with the status quo and use multilib paths" works for some people, but not others. If that's the route we have to take, we'll take it, and live with the happy accident that /libhf/ld-linux.so.3 happens to not overlap with any arch most people care about right now, but that happy accident doesn't make it the sane ongoing solution. I'm sure people can take a step back and see that without it being some "us versus them" argument.
... Adam
On Monday 09 April 2012 15:47:56 Adam Conrad wrote:
are you not just as much hindering Debian over nothing more than a path to a single file?
nope. sounds more like self inflicted pain.
To be very, very, very clea here. multilib can not solve the "different base arches on one system problem". lib/lib32/lib64/libhf/libsf will overlap as soon as you have more than one of x86, arm, power, mips, etc.
no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem". -mike
On 04/09/2012 10:19 PM, Mike Frysinger wrote:
On Monday 09 April 2012 15:47:56 Adam Conrad wrote:
are you not just as much hindering Debian over nothing more than a path to a single file?
nope. sounds more like self inflicted pain.
To be very, very, very clea here. multilib can not solve the "different base arches on one system problem". lib/lib32/lib64/libhf/libsf will overlap as soon as you have more than one of x86, arm, power, mips, etc.
no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem".
Don't the multilib paths contain enough information to handle this? They certainly have in the past as I can recall building toolchains that handled several architectures within power, arm & mips families in the past
Is the problem here that glibc simply isn't building multilib paths in the same way that GCC has for the last 15 years?
jeff
On Tuesday 10 April 2012 00:23:09 Jeff Law wrote:
On 04/09/2012 10:19 PM, Mike Frysinger wrote:
On Monday 09 April 2012 15:47:56 Adam Conrad wrote:
To be very, very, very clea here. multilib can not solve the "different base arches on one system problem". lib/lib32/lib64/libhf/libsf will overlap as soon as you have more than one of x86, arm, power, mips, etc.
no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem".
Don't the multilib paths contain enough information to handle this? They certainly have in the past as I can recall building toolchains that handled several architectures within power, arm & mips families in the past
his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions.
Is the problem here that glibc simply isn't building multilib paths in the same way that GCC has for the last 15 years?
afaik, glibc and gcc should be in sync ... can't say i've noticed issues with all the arches Gentoo supports. -mike
On 04/09/2012 10:33 PM, Mike Frysinger wrote:
his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions.
Hmmm, why would anyone want to install distinct architectures in the same root... I must admit I don't recall that being discussed at Plumbers.
Jeff
On Mon, Apr 09, 2012 at 10:38:17PM -0600, Jeff Law wrote:
On 04/09/2012 10:33 PM, Mike Frysinger wrote:
his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions.
Hmmm, why would anyone want to install distinct architectures in the same root... I must admit I don't recall that being discussed at Plumbers.
It's one of the things we're trying to achieve with multi-arch. We can support mixed-ABI, mixed-OS, mixed-architecture environments cleanly on one system, using a consistent set of packages for all. Setting up a cross-compilation environment suddenly becomes easy - install the cross-compiler and the libs for the target platform straight from a normal Debian mirror as binary packages.
See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more rationale.
We understand that not everybody may want or see the need for this for themselves. We *really* get that. But we want it to be possible for *us* to do it, and an ultra-important part of that is to have unique loader paths wherever possible. Hence the discussion over the location for the arm hard-float linker. We've built our systems using the multi-arch path as that worked well for us and doesn't hurt anybody else. There are problems with some of the other options here:
* /lib/ld-linux.so.3 - it already clashes with the soft-float ABI linker, and we 100% want to support both of those on the same system in parallel (e.g. supporting older soft-float proprietary binaries on newer hard-float systems)
* /libhf/ld-linux.so.3 - it could readily clash with a future hard-float platform; look how /lib64/* could clash with amd64/ARMv8/ppc64/sparc64 all populating it in the near future
* /lib/ld-linux-hf.so.3 - similar problem
The options I've seen enumerated that can't clash are:
* /lib/<uuid>/ld-linux.so.3 - just a joke suggestion, ignore it (please!)
* /lib/ld-linux-$triplet.so.3 - could work fine, so long as we can agree on triplets
* /lib/$triplet/ld-linux.so.3 - ditto
In Debian and Ubuntu, we have implemented the last one of these three and it's working fine for us. We had understood that in previous cross-distro discussions (e.g. at Plumbers last year) there was agreement on this, but we're now seeing dissent. Ubuntu are expecting (by the end of this month) to be the first distro to ship a stable release using the hard-float ABI on ARM, so it's unfortunate that this argument is happening now.
We have to agree on a standard path if we're ever going to have working cross-distro binaries, and that's increasingly important to us in the ARM world. By all means ignore the multi-arch route that the Debian world is following, but please accept our reasoning for the linker location.
Cheers,
On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
We understand that not everybody may want or see the need for this for themselves. We *really* get that. But we want it to be possible for *us* to do it, and an ultra-important part of that is to have unique loader paths wherever possible. Hence the discussion over the location for the arm hard-float linker. We've built our systems using the multi-arch path as that worked well for us and doesn't hurt anybody else. There are problems with some of the other options here:
- /lib/ld-linux.so.3
no one suggested this
/libhf/ld-linux.so.3
- it could readily clash with a future hard-float platform; look how /lib64/* could clash with amd64/ARMv8/ppc64/sparc64 all populating it in the near future
/lib/ld-linux-hf.so.3
- similar problem
so you're saying Debian would never accept any ldso path for any arch on the future possibility that it could collide with another target ? that's a bit unreasonable.
- /lib/ld-linux-$triplet.so.3
- could work fine, so long as we can agree on triplets
kind of a waste of space, and the definition of "triplet" is vague, and in your example here, the word "linux" uselessly appears twice.
once the duplicate "linux" word is fixed, i wouldn't fight this.
In Debian and Ubuntu, we have implemented the last one of these three and it's working fine for us. We had understood that in previous cross-distro discussions (e.g. at Plumbers last year) there was agreement on this, but we're now seeing dissent. Ubuntu are expecting (by the end of this month) to be the first distro to ship a stable release using the hard-float ABI on ARM, so it's unfortunate that this argument is happening now.
one of the downsides of traveling down a path and upstreaming as an after thought -mike
On Tue, 10 Apr 2012 23:01:47 -0400 Mike Frysinger vapier@gentoo.org wrote:
one of the downsides of traveling down a path and upstreaming as an after thought
You didn't really follow arm hardfloat progress in the past 2 years, did you (if you did you'd already be aware of attempts to get this thing upstreamed for more than a year).
Honestly, I'm curious, are you speaking your personal opinion or on behalf of Gentoo? If the former then consider that we're trying to get consensus amongst distros not people, it's impossible to make everyone happy, but we'd be content to get distro people to agree on a standard.
If the latter, then also have in mind that GCC upstream is waiting for distro agreement to include the proposed triplet (arm-linux-gnueabihf) in gcc. So, if distro people here agreed on that, gcc upstream would have no problem as well. Agreed on the redundant linux part, my mistake for proposing it. So, I guess something like:
/lib/ld-arm-linux-gnueabhif.so.3
or using the ABI name:
/lib/ld-linux-aapcs-vfp.so.3
are the most likely candidates to be agreed by most distros, at least as I see it.
Konstantinos
On Wednesday 11 April 2012 03:37:56 Konstantinos Margaritis wrote:
On Tue, 10 Apr 2012 23:01:47 -0400 Mike Frysinger wrote:
one of the downsides of traveling down a path and upstreaming as an after thought
You didn't really follow arm hardfloat progress in the past 2 years, did you (if you did you'd already be aware of attempts to get this thing upstreamed for more than a year).
i've only started following arm again as my last job (of 5+ years) was largely Blackfin related
Honestly, I'm curious, are you speaking your personal opinion or on behalf of Gentoo? If the former then consider that we're trying to get consensus amongst distros not people, it's impossible to make everyone happy, but we'd be content to get distro people to agree on a standard.
considering i did the Gentoo/ARM port ~8 years ago and maintain the toolchain on Gentoo for all arches, i have a fairly big incentive to keep things clean.
proposing it. So, I guess something like:
/lib/ld-arm-linux-gnueabhif.so.3
or using the ABI name:
/lib/ld-linux-aapcs-vfp.so.3
are the most likely candidates to be agreed by most distros, at least as I see it.
i can let the fine wording of the tuple in the filename be hammered out by others. if we don't care about multilib, then /lib/ is fine, and as long is it isn't crowed by subdir-cruft (i.e. /lib/<tuple>/), then i'm happy.
side note: you really need to fix your mailer. the lack of proper wrapping is obnoxious. -mike
On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote:
On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
We understand that not everybody may want or see the need for this for themselves. We *really* get that. But we want it to be possible for *us* to do it, and an ultra-important part of that is to have unique loader paths wherever possible. Hence the discussion over the location for the arm hard-float linker. We've built our systems using the multi-arch path as that worked well for us and doesn't hurt anybody else. There are problems with some of the other options here:
- /lib/ld-linux.so.3
no one suggested this
It's the current default.
/libhf/ld-linux.so.3
- it could readily clash with a future hard-float platform; look how /lib64/* could clash with amd64/ARMv8/ppc64/sparc64 all populating it in the near future
/lib/ld-linux-hf.so.3
- similar problem
so you're saying Debian would never accept any ldso path for any arch on the future possibility that it could collide with another target ? that's a bit unreasonable.
We're not saying "never", but we would rather avoid collisions if avoidable.
- /lib/ld-linux-$triplet.so.3
- could work fine, so long as we can agree on triplets
kind of a waste of space, and the definition of "triplet" is vague, and in your example here, the word "linux" uselessly appears twice.
We *have* had agreement on the triplet here: arm-linux-gnueabihf. Yes, "linux" is used twice here. Apologies.
once the duplicate "linux" word is fixed, i wouldn't fight this.
Thanks. \o/
Cheers,
On Wednesday 11 April 2012 05:47:29 Steve McIntyre wrote:
On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote:
On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
- /lib/ld-linux-$triplet.so.3
- could work fine, so long as we can agree on triplets
kind of a waste of space, and the definition of "triplet" is vague, and in your example here, the word "linux" uselessly appears twice.
We *have* had agreement on the triplet here: arm-linux-gnueabihf.
it wasn't clear what triplet you were referring to. Debian's multiarch has its own concept (according to its own wiki), and then there's the GNU triplet. -mike
On 04/10/2012 04:42 AM, Steve McIntyre wrote:
It's one of the things we're trying to achieve with multi-arch. We can support mixed-ABI, mixed-OS, mixed-architecture environments cleanly on one system, using a consistent set of packages for all. Setting up a cross-compilation environment suddenly becomes easy - install the cross-compiler and the libs for the target platform straight from a normal Debian mirror as binary packages.
See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more rationale.
I've read it and still don't see the benefit, particularly as it relates to mixed instruction sets. Or more precisely, I don't see the value in supporting mixed instruction sets. Once you drop the mixed instruction set argument I think the whole argument for embedding the target triplet into the dynamic linker pathname falls apart.
We have to agree on a standard path if we're ever going to have working cross-distro binaries, and that's increasingly important to us in the ARM world. By all means ignore the multi-arch route that the Debian world is following, but please accept our reasoning for the linker location.
But the entire reason behind the need to embed the triplet into the dynamic linker's path is the debian multi-arch stuff AFAICT. I think that's what many folks are complaining about.
I realize the goal here is to allow a single binary to run on multiple systems and I think that's a worthy goal.
Jeff
On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
On 04/10/2012 04:42 AM, Steve McIntyre wrote:
It's one of the things we're trying to achieve with multi-arch. We can support mixed-ABI, mixed-OS, mixed-architecture environments cleanly on one system, using a consistent set of packages for all. Setting up a cross-compilation environment suddenly becomes easy - install the cross-compiler and the libs for the target platform straight from a normal Debian mirror as binary packages.
See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more rationale.
I've read it and still don't see the benefit, particularly as it relates to mixed instruction sets. Or more precisely, I don't see the value in supporting mixed instruction sets. Once you drop the mixed instruction set argument I think the whole argument for embedding the target triplet into the dynamic linker pathname falls apart.
We see a value in supporting mixed instruction sets for two cases: emulation and cross-building. If you don't want or care so much about those, then fine - that's your call in your environment. They're both cases that Debian/Ubuntu would like to do a much better job of supporting in future, using existing packages instead of having to do so much special-casing all over. I hope that you (plural) can understand/accept that?
We have to agree on a standard path if we're ever going to have working cross-distro binaries, and that's increasingly important to us in the ARM world. By all means ignore the multi-arch route that the Debian world is following, but please accept our reasoning for the linker location.
But the entire reason behind the need to embed the triplet into the dynamic linker's path is the debian multi-arch stuff AFAICT. I think that's what many folks are complaining about.
I realize the goal here is to allow a single binary to run on multiple systems and I think that's a worthy goal.
Cool. :-)
Cheers,
Em 11 de abril de 2012 10:04, Steve McIntyre steve.mcintyre@linaro.org escreveu:
On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
On 04/10/2012 04:42 AM, Steve McIntyre wrote:
It's one of the things we're trying to achieve with multi-arch. We can support mixed-ABI, mixed-OS, mixed-architecture environments cleanly on one system, using a consistent set of packages for all. Setting up a cross-compilation environment suddenly becomes easy - install the cross-compiler and the libs for the target platform straight from a normal Debian mirror as binary packages.
See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more rationale.
I've read it and still don't see the benefit, particularly as it relates to mixed instruction sets. Or more precisely, I don't see the value in supporting mixed instruction sets. Once you drop the mixed instruction set argument I think the whole argument for embedding the target triplet into the dynamic linker pathname falls apart.
We see a value in supporting mixed instruction sets for two cases: emulation and cross-building. If you don't want or care so much about those, then fine - that's your call in your environment. They're both cases that Debian/Ubuntu would like to do a much better job of supporting in future, using existing packages instead of having to do so much special-casing all over. I hope that you (plural) can understand/accept that?
Probably beating a dead cow, but, the major problem with sysroots would be the triplet name?
E.g, in any architecture:
/arm-linux-gnueabi/sysroot-contents-here
and ld.so living in
/arm-linux-gnueabi/lib/ld.so.3
and arch specific package cross toolchain in:
/this-system-triplet/bin/arm-linux-gnueabi-gcc etc
with kernel support, as already suggested in this thread, one could omit the /x-y-z part, but that is not something to be done "for yesterday".
And then the triplet name problem:
/armv7hl-vendor-linux-gnueabi/lib/ld.so.3 or /arm-linux-gnueabihf/lib/ld.so.3
With this approach, not pretending to share files between sysroots, that can be easily done, but requires strong policy to not allow binaries in /usr/share if /usr/share it to be, err "shared".
We have to agree on a standard path if we're ever going to have working cross-distro binaries, and that's increasingly important to us in the ARM world. By all means ignore the multi-arch route that the Debian world is following, but please accept our reasoning for the linker location.
But the entire reason behind the need to embed the triplet into the dynamic linker's path is the debian multi-arch stuff AFAICT. I think that's what many folks are complaining about.
I realize the goal here is to allow a single binary to run on multiple systems and I think that's a worthy goal.
Cool. :-)
Cheers,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
Paulo
On Wednesday 11 April 2012 11:25:55 Paulo César Pereira de Andrade wrote:
Probably beating a dead cow, but, the major problem with sysroots would be the triplet name?
E.g, in any architecture:
/arm-linux-gnueabi/sysroot-contents-here
it isn't really about having a sysroot the toolchain can find. that already works today for any target or multilib or isa or soft/hard float or arch or <anything>. the issue is having an ldso in its canonical path for runtime usage. i don't think anyone wants hardcoded tuple dirs in the root. some people can't even handle /bin or /sbin or /lib, so i'm afraid this proposal would cause them to implode ;). -mike
All,
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
regards Ravi Singh
"Singh, Ravi Kumar (Ravi)" Ravi.Singh@lsi.com wrote:
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
You'd have to place the chunk of code into a separate file and build it with a different set of options ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On 11 April 2012 16:16, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
"Singh, Ravi Kumar (Ravi)" Ravi.Singh@lsi.com wrote:
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
Are you saying __attribute__((optimise("foo"))) is a lie?
On 12 April 2012 04:21, Mans Rullgard mans.rullgard@linaro.org wrote:
On 11 April 2012 16:16, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
"Singh, Ravi Kumar (Ravi)" Ravi.Singh@lsi.com wrote:
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
Are you saying __attribute__((optimise("foo"))) is a lie?
It seems to work on 4.6 on public functions:
void doubleit(int *pout, const int *pin) { for (int i = 0; i < 64; i++) { pout[i] = pin[i]*2; } }
(gets vectorised)
__attribute__((optimize("-fno-tree-vectorize"))) void novect(int *pout, const int *pin) { for (int i = 0; i < 64; i++) { pout[i] = pin[i]*2; } }
(no vector code)
The attribute applies to that function only and doesn't seem to apply if the function is inlined, such as:
__attribute__((optimize("-fno-tree-vectorize"))) static void novect(int *pout, const int *pin) ...
void outer(int *pin, int *pout) { novect(pout, pin); }
'outer' contains vectorised code.
-- Michael
On 11 April 2012 17:21, Mans Rullgard mans.rullgard@linaro.org wrote:
On 11 April 2012 16:16, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
"Singh, Ravi Kumar (Ravi)" Ravi.Singh@lsi.com wrote:
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
Are you saying __attribute__((optimise("foo"))) is a lie?
Function attributes aren't really the same as pragmas :)
regards, Ramana
On 11 April 2012 22:05, Ramana Radhakrishnan ramana.radhakrishnan@linaro.org wrote:
On 11 April 2012 17:21, Mans Rullgard mans.rullgard@linaro.org wrote:
On 11 April 2012 16:16, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
"Singh, Ravi Kumar (Ravi)" Ravi.Singh@lsi.com wrote:
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
Are you saying __attribute__((optimise("foo"))) is a lie?
Function attributes aren't really the same as pragmas :)
Use #pragma GCC optimize ("foo") then. It does the same thing if the manual is to be believed.
Mans Rullgard mans.rullgard@linaro.org wrote on 11.04.2012 18:21:46:
On 11 April 2012 16:16, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
"Singh, Ravi Kumar (Ravi)" Ravi.Singh@lsi.com wrote:
Are there any pragmas for selectively disabling (in one chunk of code) the vectorization, when its enabled globally.
No, there are not (just like for all optimization settings).
Are you saying __attribute__((optimise("foo"))) is a lie?
No, you're of course correct. __attribute__((optimize)) is supposed to work, as is #pragma GCC optimize.
[ The reason I said otherwise was that I erroneously thought this attribute required back-end support which we don't have on ARM yet. I guess I mixed this up with __attribute__((target)), which indeed is not supported on ARM. ]
Sorry for causing extra confusion.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On 04/10/2012 12:38 AM, Jeff Law wrote:
On 04/09/2012 10:33 PM, Mike Frysinger wrote:
his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions.
Hmmm, why would anyone want to install distinct architectures in the same root... I must admit I don't recall that being discussed at Plumbers.
So with multi-arch, you can do system emulation on the fly or whatever else you feel like doing today. It's technically cute, but of no interest to Fedora. However, here we're solely concerned with the path to the linker, which we do incidentally need to fix (and the proposal that we adopt the same one that happens to be used by multi-arch is entirely reasonable on technical grounds).
Here's my viewpoint:
1). We do need a single linker path[0] so that someone can build a binary on Ubuntu or Fedora and have it work on the other distro.
2). The linker path should ideally be identical (the one compiled into the ELF header - whether that is the original path, or a symlink to a symlink...) so that we don't get a situation wherein binaries built for one distro won't run on the other, or the inverse. Selfishly, I care that everyone uses Fedora to build stuff and then it "just works" on Debian or Ubuntu (if they feel so inclined), not the other way around. That's my motive right there to care that we all agree on this :)
3). There exists no technical reason to oppose using the multi-arch path that we had discussed previously. I think we would be best served clearly separating a single file (as Adam has note on many occasions) from the bigger issue of multi-arch that is "not loved" everywhere. If we can do that, I think we can then go to the step of advocating to do this upstream, and pull it into Fedora's ARM port. I'd go as far as to say that this is an ARM specific issue on the Fedora end, and thus we don't really need the entire Fedora community to change one path.
4). Frankly, whether or not we like the Ubuntu approach - and I'm going to be careful here so I'm not quoted out of context - they are shipping a 5 year LTS release of Ubuntu on ARM. Since they are the first to do an ARM release of that nature, they are setting a platform precedent in their actions that those of us with 6 or 12 month cycles don't have. We are in an easier position to get with the program than they are by now. I hope we've all learned a lesson for AArch64, live and learn.
Anyway. My proposal is that we all join the call that Steve is putting together on Thursday pm/eve, using my Red Hat bridge. He'll send out the information. I would very much appreciate it if you (Jeff) could join because you are widely known as a calming voice of reason and sanity (if only you scaled to the point we could have one of you on every call). I would also like it very much if anyone in the Fedora community who wants to share their input could also dial into that meeting. Let's have this out, get it finally nailed down, and move on.
Thanks everyone,
Jon.
[0] If we're even going to fool ourselves even remotely into believing in cross-distribution binary compatibility. I'm a true believer in having binaries that just work, but it's not the new shiny any more. Everyone loves to hate LSB so much but they never try to improve it.
On Tue, Apr 10, 2012 at 05:56:38PM -0400, Jon Masters wrote:
Anyway. My proposal is that we all join the call that Steve is putting together on Thursday pm/eve, using my Red Hat bridge. He'll send out the information. I would very much appreciate it if you (Jeff) could join because you are widely known as a calming voice of reason and sanity (if only you scaled to the point we could have one of you on every call). I would also like it very much if anyone in the Fedora community who wants to share their input could also dial into that meeting. Let's have this out, get it finally nailed down, and move on.
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.
Cheers,
Steve,
Can you make sure the Mentor folks are invited to the party on the glibc end? Suggest sending this to one of the main glibc lists.
Jon.
Hi Steve,
Please ensure Jakub on our end is involved in the meeting. We discussed compromise solutions that are acceptable to him and Dennis today and I would like him to be involved in the discussion. He is on CET, but cannot make calls after 10pm UTC. I prefer that we try to have this on Friday, or Monday at this point so that everyone has chance to make it.
Jon.
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.
Phone numbers are listed in the wiki page above. I'll take notes and post minutes afterwards. Let's talk Friday and get this shaken out to a working conclusion.
Thanks,
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
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
Other variant could be
/armv7hl-linux/lib/ld.so.3
but that only if one wants to implement multiarch with sysroot set to /armv7hl-linux, but that creates several other issues...
I'm happy to do the GLIBC and GCC implementation.
-- Michael
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
Paulo
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.
Other variant could be
/armv7hl-linux/lib/ld.so.3
This introduces both a new directory and a new style for naming :)
-- Michael
On 04/11/2012 05:16 PM, Michael Hope wrote:
2012/4/12 Paulo César Pereira de Andrade
/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.
In Fedora we specifically mean VFPv3-D16 when we're talking about hard float. This is the lowest common denominator for us. If you want to support armv5hl, armv6hl, and armv7hl as all being possible (whatever string you like to represent it) that's good to know because it's beyond what we're contemplating.
+++ Michael Hope [2012-04-12 12:16 +1200]:
2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
Sorry for more bikeshedding, /lib/ld-linux-armv7hl.so.3
I'd rather drop the 'l'
We've already had the GNU triplet-name argument for this ABI. I don't think having it again in order to use something slightly different for the linker name is very helpful.
Unless of course we find that was another chimera and in fact that's not really agreed either...
Wookey
On 12 April 2012 12:38, Wookey wookey@wookware.org wrote:
+++ Michael Hope [2012-04-12 12:16 +1200]:
2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
Sorry for more bikeshedding, /lib/ld-linux-armv7hl.so.3
I'd rather drop the 'l'
We've already had the GNU triplet-name argument for this ABI. I don't think having it again in order to use something slightly different for the linker name is very helpful.
Unless of course we find that was another chimera and in fact that's not really agreed either...
Sorry, I should have said that in my reply. I agree, the GNU triplet should be used. I couldn't resist going into the past-covered reasons why.
-- Michael
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).
Other variant could be
/armv7hl-linux/lib/ld.so.3
This introduces both a new directory and a new style for naming :)
Well, I said I was sorry for more bikeshedding :-)
-- Michael
Paulo
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.
-- Michael
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
On Wed, 11 Apr 2012 20:44:22 -0300 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
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
I dont see the need for linux there
/lib/ld-armv7hl.so.3
or just
/lib/ld-armhfp.so.3
64 bit could be /lib64/ld-armhfp.so.3 or /lib64/ld-aarch64.so.3
off topic but i find aarch64 weird and too generic is it arm alpha amd atom.
we shouldnt use any triplet since they are not standard between distros,
Dennis
On Apr 11, 2012, at 7:22 PM, Michael Hope wrote:
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.
I'm happy with your proposal, as I am with any of the others that result in a /lib path (our guys will accept that) that contains enough uniqueness that there won't be a path clash later. Sure, Jakub will probably argue that ".so.3" already implies "gnueabi" so we can drop that, and we can screw around with this some more, but you are on the right track IMO.
Jon.
On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures. Note e.g. x86_64 dynamic linker is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2. For distros that choose to multilib softfp vs. hardfp all the hardfp libraries would go into the usual */lib{qual} paths (for qual hf resp. hfp), for others /libhf can be a symlink to /lib or for those doing multiarch stuff can be a symlink to the multiarch location of the thing.
I'm fine with arm and hf (resp. hfp) being mentioned in the name of the dynamic linker, but IMNSHO having there gnu and eabi strings is an overkill - why mention gnu there, when all the other architectures which also have GNU libc dynamic linkers don't? That part is implicit. And, EABI is implied by so.3, softfp dynamic linker for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old ABI is /lib/ld-linux.so.2.
Jakub
On 12 April 2012 09:05, Jakub Jelinek jakub@redhat.com wrote:
On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures. Note e.g. x86_64 dynamic linker is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
For some value of consistency. x86_64, mips64, powerpc64 and sparc64 install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on s390x it is /lib/ld64.so.1 [1].
For distros that choose to multilib softfp vs. hardfp all the hardfp libraries would go into the usual */lib{qual} paths (for qual hf resp. hfp), for others /libhf can be a symlink to /lib or for those doing multiarch stuff can be a symlink to the multiarch location of the thing.
My qualm with /libhf is that it is currently used by nobody. But in a way it is fair compromise where no distro gets preferential treatment - everyone will have to move files around.
Riku
On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
On 12 April 2012 09:05, Jakub Jelinek jakub@redhat.com wrote:
On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures. Note e.g. x86_64 dynamic linker is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
For some value of consistency. x86_64, mips64, powerpc64 and sparc64 install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on
ia64 installs in /lib, because it isn't a multilibbed architecture.
s390x it is /lib/ld64.so.1 [1].
Ok, I forgot about this, I've tried to convince s390x folks to move it to /lib64/ld64.so.1 many years ago, but that just didn't happen, so /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1. Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker, while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc.
That is an argument that perhaps /lib/ld-linux-armhf.so.3 could be acceptable too, as it would follow the s390x model, I wouldn't be terribly happy about that, but I could live with that.
Jakub
On Thursday 12 April 2012 03:47:29 Jakub Jelinek wrote:
On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
On 12 April 2012 09:05, Jakub Jelinek jakub@redhat.com wrote:
On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures. Note e.g. x86_64 dynamic linker is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
For some value of consistency. x86_64, mips64, powerpc64 and sparc64 install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on
ia64 installs in /lib, because it isn't a multilibbed architecture.
because distros choose not to support it. in first gen chips, there was hardware support for running x86. so if we were to be strict, there should have been /libia64/ (or whatever) while the current x86 32bit code would stay in /lib/. but no distro was interested in supporting that (probably due to the 32bit x86 layers being balls-ass slow), so it never happened.
s390x it is /lib/ld64.so.1 [1].
Ok, I forgot about this, I've tried to convince s390x folks to move it to /lib64/ld64.so.1 many years ago, but that just didn't happen, so /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1. Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker, while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc.
i always thought this was weird. glad to know i'm not the only one :). -mike
On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
ia64 installs in /lib, because it isn't a multilibbed architecture.
because distros choose not to support it. in first gen chips, there was hardware support for running x86. so if we were to be strict, there should have been /libia64/ (or whatever) while the current x86 32bit code would stay in /lib/. but no distro was interested in supporting that (probably due to the 32bit x86 layers being balls-ass slow), so it never happened.
We even carried patches (not applied) for lib64 ia64 support in our binutils/glibc/gcc for a while, but the final decision after these were written was that it is going to stay in /lib.
Jakub
On Thursday 12 April 2012 13:53:13 Jakub Jelinek wrote:
On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
ia64 installs in /lib, because it isn't a multilibbed architecture.
because distros choose not to support it. in first gen chips, there was hardware support for running x86. so if we were to be strict, there should have been /libia64/ (or whatever) while the current x86 32bit code would stay in /lib/. but no distro was interested in supporting that (probably due to the 32bit x86 layers being balls-ass slow), so it never happened.
We even carried patches (not applied) for lib64 ia64 support in our binutils/glibc/gcc for a while, but the final decision after these were written was that it is going to stay in /lib.
true, it would have been /lib64/ since the hardware doesn't the 64bit extensions for x86. but i think the point still stands that using /lib/ for the new hardfloat ABI is OK rather than needing to go the /libhf/ multilib route.
and, if it turns out that we were being too optimistic and we do actually want soft/hard float multilib, i don't think this will be a blocker. as mentioned, the s390x guys have been bad and it hasn't been a blocker for s390/s390x multilib with them :). -mike
On Thursday 12 April 2012 02:05:23 Jakub Jelinek wrote:
On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures.
i think the idea was that no one is looking to do multilib here. so we won't have softfloat in /lib/ and hardfloat in /libhf/. we're just changing the ldso to reflect a change in the ABI.
you could also make this argument for EABI and OABI -- the EABI ldso should not be in /lib/. but since we've got OABI and EABI both in /lib/ and people are happy with that, as well as the hardfloat ldso in /lib/, there's no need for a sep /libhf/.
I'm fine with arm and hf (resp. hfp) being mentioned in the name of the dynamic linker, but IMNSHO having there gnu and eabi strings is an overkill - why mention gnu there, when all the other architectures which also have GNU libc dynamic linkers don't? That part is implicit. And, EABI is implied by so.3, softfp dynamic linker for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old ABI is /lib/ld-linux.so.2.
i have no opinion either way here. uClibc has already opted to name things with "-uClibc-" in them, so we're clear of collisions there. -mike
Em 12 de abril de 2012 03:05, Jakub Jelinek jakub@redhat.com escreveu:
On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures. Note e.g. x86_64 dynamic linker is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2. For distros that choose to multilib softfp vs. hardfp all the hardfp libraries would go into the usual */lib{qual} paths (for qual hf resp. hfp), for others /libhf can be a symlink to /lib or for those doing multiarch stuff can be a symlink to the multiarch location of the thing.
I would feel a bit better with a commitment for multilib if using /libhf, but really just to make users life easier. Providing the infrastructure (by having multilib packages) is asking for it to be used. In the skype example, if multilib is supported by all distros, skype may as well provide only an armv5te software float build for linux arm. This is the reason, for example, to install skype in my x86_64 computer I need to install 32 bit qt, alsa, X11 libraries, etc to be able to install x86 skype.
I'm fine with arm and hf (resp. hfp) being mentioned in the name of the dynamic linker, but IMNSHO having there gnu and eabi strings is an overkill - why mention gnu there, when all the other architectures which also have GNU libc dynamic linkers don't? That part is implicit. And, EABI is implied by so.3, softfp dynamic linker for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old ABI is /lib/ld-linux.so.2.
Jakub
Paulo
On Mon, Apr 02, 2012 at 03:04:11PM -0400, Mike Frysinger wrote:
On Mon, Apr 2, 2012 at 09:19, Riku Voipio riku.voipio@linaro.org wrote:
On 31 March 2012 19:52, Dennis Gilmore dennis@gilmore.net.au wrote:
Linaro Connect and other events are probably the worst place for such decisions and discussions to be made. though maybe there is not a good place. the wider community needs to be engaged for greatest acceptance. otherwise then if falls into the vacuum of those attending the events. Like I said its not that it could never happen just that its not been discussed at all. so requesting that distros adopt it is a bit harsh and unrealistic.
At Linaro conference the need for changing linker path was agreed on, as well as the need to get a wide community agreement on it. To do the latter, an ARM minisummit was organized on at Plumbers 2011 [1]. Invites to wide range communities and distributions were sent, and for most someone attended. For the people not able to join physically, a call-in line was organized (I was on the call for example). With the expectation that people who attended in face or on call would convey the message back to their own communities. This didn't seemingly happen for everyone it seems.
i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though.
I don't see how this forces anyone to implement multi-arch - and I think if that was our agenda, this would be a pretty weak angle for us to take :)
this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline.
You make it sound so sinister! I assure you that making changes like this "behind-the-back" is far from our goal. It has even been brought up for discussion on this very list: http://lists.linaro.org/pipermail/cross-distro/2011-October/000078.html
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Jon.
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
-- Michael
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Jon.
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
-- Michael
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
-- Michael
On 05/02/2012 12:15 AM, Michael Hope wrote:
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
Yup. I think Dennis has pinged Jakub about it. Dennis, do we need to do anything else on our end? I think we've got the symlink handled, etc.?
Jon.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 02 May 2012 00:39:37 -0400 Jon Masters jcm@redhat.com wrote:
On 05/02/2012 12:15 AM, Michael Hope wrote:
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
Yup. I think Dennis has pinged Jakub about it. Dennis, do we need to do anything else on our end? I think we've got the symlink handled, etc.?
Jon.
Jakub will pull tha patches in when glibc is also fixed.
Dennis
On 05/02/2012 01:38 PM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 02 May 2012 00:39:37 -0400 Jon Masters jcm@redhat.com wrote:
On 05/02/2012 12:15 AM, Michael Hope wrote:
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote: > Hey everyone, > > Following up here. Where do we stand? We need to have upstream > patches before we can pull them into the distro - is that piece > done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
Yup. I think Dennis has pinged Jakub about it. Dennis, do we need to do anything else on our end? I think we've got the symlink handled, etc.?
Jon.
Jakub will pull tha patches in when glibc is also fixed.
Right. So then, the question is where we stand with GLIBC, Carlos?
Jon.
On Wed, May 2, 2012 at 5:34 PM, Jon Masters jcm@redhat.com wrote:
Right. So then, the question is where we stand with GLIBC, Carlos?
It's going through Mentor's build/test cycle right now with the new gcc patch and a revised glibc patch.
Cheers, Carlos.
On 05/02/2012 09:24 PM, Carlos O'Donell wrote:
On Wed, May 2, 2012 at 5:34 PM, Jon Masters jcm@redhat.com wrote:
Right. So then, the question is where we stand with GLIBC, Carlos?
It's going through Mentor's build/test cycle right now with the new gcc patch and a revised glibc patch.
Did I mention you rock? In case I neglected it. You rock. And so does Michael, and Steve, and Dennis, and in fact everyone rocks. Beer next time I see any of you (and more coffee for me!)
Jon.
On Wed, May 2, 2012 at 10:57 PM, Jon Masters jcm@redhat.com wrote:
On 05/02/2012 09:24 PM, Carlos O'Donell wrote:
On Wed, May 2, 2012 at 5:34 PM, Jon Masters jcm@redhat.com wrote:
Right. So then, the question is where we stand with GLIBC, Carlos?
It's going through Mentor's build/test cycle right now with the new gcc patch and a revised glibc patch.
Did I mention you rock? In case I neglected it. You rock. And so does Michael, and Steve, and Dennis, and in fact everyone rocks. Beer next time I see any of you (and more coffee for me!)
Michael's GCC patches look good.
I've posted another set of WIP patches for glibc. http://sourceware.org/ml/libc-ports/2012-05/msg00014.html
I'm waiting for some more feedback right now, and another round of tests to finish.
Cheers, Carlos.
On 2 May 2012 05:15, Michael Hope michael.hope@linaro.org wrote:
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
I noticed that it now sets the dynamic loader to /lib/ld-linux-armhf.so.3 even when configured for soft-float ABI and linking against a soft-float rootfs. The resulting binaries then fail to run. Passing -mfloat-abi=softfp to the link command fixes it. Is this change in behaviour intentional?
On 02/05/12 13:25, Mans Rullgard wrote:
On 2 May 2012 05:15, Michael Hope michael.hope@linaro.org wrote:
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote:
Hey everyone,
Following up here. Where do we stand? We need to have upstream patches before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
I noticed that it now sets the dynamic loader to /lib/ld-linux-armhf.so.3 even when configured for soft-float ABI and linking against a soft-float rootfs. The resulting binaries then fail to run. Passing -mfloat-abi=softfp to the link command fixes it. Is this change in behaviour intentional?
Eh? Exactly what command line did you invoke the compiler with, and what was the configuration? Are you sure you don't have a compiler configured to hard-float by default?
R.
On 2 May 2012 13:42, Richard Earnshaw rearnsha@arm.com wrote:
On 02/05/12 13:25, Mans Rullgard wrote:
On 2 May 2012 05:15, Michael Hope michael.hope@linaro.org wrote:
On 27 April 2012 11:59, Michael Hope michael.hope@linaro.org wrote:
On 23 April 2012 14:23, Jon Masters jcm@redhat.com wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
On 21 April 2012 09:10, Jon Masters jcm@redhat.com wrote: > Hey everyone, > > Following up here. Where do we stand? We need to have upstream patches > before we can pull them into the distro - is that piece done?
Hi Jon. I've been away, sorry. I've just sent the GCC patch and Carlos is on the hook for the GLIBC side.
I saw the email. Could folks do me a favor and let me know the moment this lands in upstream and I'll arrange for us to pull it immediately.
(I'm on all the libc lists, but then I'm on almost every list, everywhere, so it takes a bit of time to get to it)
Hi Jon. There's a fault with the GCC patch so it's still in progress. Carlos sent the GLIBC patch out for review today.
Hi Jon. The GCC patch is now upstream as r186859 and r187012.
I noticed that it now sets the dynamic loader to /lib/ld-linux-armhf.so.3 even when configured for soft-float ABI and linking against a soft-float rootfs. The resulting binaries then fail to run. Passing -mfloat-abi=softfp to the link command fixes it. Is this change in behaviour intentional?
Eh? Exactly what command line did you invoke the compiler with, and what was the configuration? Are you sure you don't have a compiler configured to hard-float by default?
It happens even with the simplest possible "arm-linux-gnueabi-gcc foo.c" command. The compiler is definitely using the soft-float ABI.
Output of -v:
Using built-in specs. COLLECT_GCC=arm-unknown-linux-gnueabi-gcc-4.8.0 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-unknown-linux-gnueabi/4.8.0/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: /tmp/portage/cross-arm-unknown-linux-gnueabi/gcc-4.8.0_alpha20120429/work/gcc-4.8-20120429/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-unknown-linux-gnueabi/gcc-bin/4.8.0 --includedir=/usr/lib/gcc/arm-unknown-linux-gnueabi/4.8.0/include --datadir=/usr/share/gcc-data/arm-unknown-linux-gnueabi/4.8.0 --mandir=/usr/share/gcc-data/arm-unknown-linux-gnueabi/4.8.0/man --infodir=/usr/share/gcc-data/arm-unknown-linux-gnueabi/4.8.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-unknown-linux-gnueabi/4.8.0/include/g++-v4 --host=x86_64-pc-linux-gnu --target=arm-unknown-linux-gnueabi --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/arm-unknown-linux-gnueabi/4.8.0/python --enable-checking=release --disable-libgcj --disable-libquadmath --enable-languages=c,c++ --with-sysroot=/usr/arm-unknown-linux-gnueabi --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.0_alpha20120429' Thread model: posix gcc version 4.8.0 20120429 (experimental) (Gentoo 4.8.0_alpha20120429)
linaro-toolchain@lists.linaro.org
-
Adam Conrad -
Brendan Conoboy -
Carlos O'Donell -
dann frazier -
Dennis Gilmore -
Jakub Jelinek -
Jeff Law -
Jon Masters -
Jon Masters -
Konstantinos Margaritis -
Mans Rullgard -
Matthias Klose -
Michael Hope -
Mike Frysinger -
Paulo César Pereira de Andrade -
Ramana Radhakrishnan -
Richard Earnshaw -
Riku Voipio -
Singh, Ravi Kumar (Ravi) -
Steve McIntyre -
Ulrich Weigand -
Wookey