On 4 April 2012 04:17, Andrew Haley aph@redhat.com wrote:
On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
On 03/04/12 12:01, Jakub Jelinek wrote:
On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
If, so then there's only one way to sort out this mess.
/lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
The above scheme is a Debianism which no other distro is using.
Jakub
Not really, it's just a naming convention for where the config-specific dynamic loader lives. It doesn't affect where the remaining shared libraries live.
The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros.
This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad.
I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64.
(cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that)
I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things.
No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros.
-- Michael
[1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros.
This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad.
I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64.
(cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that)
I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things.
Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine.
No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros.
Isn't e.g. Fedora 17/armv7hl a hard float based distro?
Jakub
On 4 April 2012 11:11, Jakub Jelinek jakub@redhat.com wrote:
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros.
This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad.
I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64.
(cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that)
I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things.
Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine.
No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros.
Isn't e.g. Fedora 17/armv7hl a hard float based distro?
Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding:
Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build
Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported
Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float
openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build
Gentoo: * I'm unsure (help?) * The Gentoo manual suggests ARMv7 softfp is the default
-- Michael
On Wed, Apr 4, 2012 at 12:48 AM, Michael Hope michael.hope@linaro.org wrote:
On 4 April 2012 11:11, Jakub Jelinek jakub@redhat.com wrote:
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros.
This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad.
I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64.
(cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that)
I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things.
Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine.
No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros.
Isn't e.g. Fedora 17/armv7hl a hard float based distro?
Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding:
Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build
Beta isn't far off and we're working toward Primary Arch.
Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported
Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float
openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build
Is only hard float, they haven't ruled out doing v5 soft float but it's not their current focus.
Peter
Em 3 de abril de 2012 20:48, Michael Hope michael.hope@linaro.org escreveu:
On 4 April 2012 11:11, Jakub Jelinek jakub@redhat.com wrote:
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros.
This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad.
I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64.
(cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that)
I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things.
Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine.
No one has released a hard float based distro yet. We have time to discuss and fix this so we don't get in the crazy situation where a third party binary only runs on some distros.
Isn't e.g. Fedora 17/armv7hl a hard float based distro?
Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding:
Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build
Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported
Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float
openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build
Gentoo: * I'm unsure (help?) * The Gentoo manual suggests ARMv7 softfp is the default
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
-- Michael
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
Paulo
2012/4/4 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
Em 3 de abril de 2012 20:48, Michael Hope michael.hope@linaro.org escreveu:
<snip>
Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo. None have been released yet. Here's my understanding:
Fedora 17: * ARM is a secondary architecture * Alpha 1 release is out * Has both a ARMv5 soft float and ARMv7 hard float build
Ubuntu Precise: * ARM is a primary architecture * Beta 2 is out * ARMv7 hard float by default with ARMv7 softfp being community supported
Debian: * ARM is a primary architecture * Has a ARMv4T soft float and in-development ARMv7 hard float
openSUSE: * Kicked off at a hackfest in September 2011 * Have a ARMv5T soft float and ARMv7 hard float build
Gentoo: * I'm unsure (help?) * The Gentoo manual suggests ARMv7 softfp is the default
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
-- Michael
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those that choose the Debian layout instead, if it is added somehow configurable into upstream gcc/glibc of course handle it similarly there. I just wonder why that hasn't been done 10 years ago and only needs doing now (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
One needs to wonder also why arm hasn't switched to 128-bit long double when all other mainstream architectures did (I hope at least aarch64 will use it by default).
Jakub
On Wed, 4 Apr 2012, Jakub Jelinek wrote:
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those that choose the Debian layout instead, if it is added somehow configurable into upstream gcc/glibc of course handle it similarly there. I just wonder why that hasn't been done 10 years ago and only needs doing now (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Exactly. The default should follow the existing practice for other architectures.
One needs to wonder also why arm hasn't switched to 128-bit long double when all other mainstream architectures did (I hope at least aarch64 will use it by default).
The AArch64 ABI (generic, not GNU/Linux, and draft, still subject to incompatible change) is public and used 128-bit long double the last time I checked.
My presumption is that there has been no demand for long double wider than double among 32-bit ARM users.
On 4 April 2012 18:54, Jakub Jelinek jakub@redhat.com wrote:
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc
OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think.
and for those that choose the Debian layout instead, if it is added somehow configurable into upstream gcc/glibc of course handle it similarly there.
Agreed.
I just wonder why that hasn't been done 10 years ago and only needs doing now
FPUs have only become common on ARM in the last few years. softfp was a good interim work around but performance is significantly better with hard float.
(of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only.
-- Michael
On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
On 4 April 2012 18:54, Jakub Jelinek jakub@redhat.com wrote:
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc
OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think.
The problem here that everyone !Debian isn't taking into account is that multilib paths don't solve our use-case. Multilib paths only solve the case of multiple ABIs on the same base processor family. As soon as you combine x86, arm, power, etc, you end up with overlaps (or, the potential for overlaps; the fact that various arches accidentally have different majors keeps those overlaps to a minimum right now, but that's not by design).
Honestly, this is something we should have solved two decades ago, but the very idea that someone would want to do what Debian is now doing didn't occur to any of us. That's cool. We didn't think of it back then. That's no excuse to continue with the status quo just because it's the status quo.
To be perfectly clear here, we don't care where the linker goes (really, we don't), we just want it to be both arch and ABI unique. If that means taking a crc32 of a rot-13 of the compiler flags used to define the ABI, and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it.
If this means setting up a (very) lightweight process with the LSB, where everytime a new distro proposes a shiny new arch/ABI, they submit it, and the LSB assigns them an ABI serial, and we all then agree to toss the linker in /lib/abi-00002345/ld-linux, that works too. Don't care. Really don't care.
This isn't about trying to force people to switch from multilib to multi- arch, where the former is clearly working fine for them. It's not. This is purely about people bikeshedding about paths they consider un-pretty, while (I hope not maliciously or knowingly?) causing potential overlap and breakage for those of us for whom this actually matters and isn't purely a color selection exercise.
In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for us, purely because that doesn't overlap with any other linkers that Debian currently ships. The fact that the multilib path happens to work doesn't make it correct for our use-case, and certainly doesn't make it correct ongoing.
Ultimately, however, I want this solved. We thought we had this solved at Plumbers last fall. To hear now that we "didn't involve everyone" is disheartening, given that we ("we" being Debian and Ubuntu) were well outnumbered in that room by people from RedHat, Fedora, ChromeOS, and Gentoo. We all agreed on something back then, and now that I'm three weeks away from shipping an armhf distro, it's all exploded yet again into Bikeshed Part III: The Revenge of Purple Paint.
I really want to ship a compiler than stuffs the "correct" and agreed upon linker in headers. I don't want to see third parties build binaries on Ubuntu that don't run on Fedora. No one wants to see that, I think.
Obviously, conversely (though this is much less hassle), I need to be able to ship a linker symlink that matches expectations, so that binaries built on Fedora will run on Ubuntu. Again, I'm sure we all want that.
So, pretty please, can we (A) address the concerns here without people putting up the "Unique paths are Debian trying to force multi-arch on us" straw man, and (B) agree to *something*, before I ship something that conforms to a standard agreed upon more than half a year ago that is now a cause for contention? Pretty please? With sugar on top? Kthx.
(of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only.
I expect that most distros will probably ship their aarch64 libraries in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent with their other 64-bit ports, but where you put libraries is entirely unrelated to where the linker lives. You could have all your libraries in /root/.trash/ and if the linker lives in a canonical location and can resolve that, that's fine. I will still (obviously, I think, from my comments above) argue that the linker should live in a guaranteed unique location. Overlap with other arches in /lib64 is certainly far more likely than overlap in /libhf.
... Adam Conrad
On Monday 09 April 2012 16:48:06 Adam Conrad wrote:
On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
On 4 April 2012 18:54, Jakub Jelinek wrote:
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc
OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think.
The problem here that everyone !Debian isn't taking into account is that multilib paths don't solve our use-case. Multilib paths only solve the case of multiple ABIs on the same base processor family. As soon as you combine x86, arm, power, etc, you end up with overlaps
and the problem there is that you're assuming anyone !Debian sees this as a problem. so, once again, do not use the armhf standardization work to backdoor multiarch. if you want to talk about multiarch, then start a new thread to do that.
Ultimately, however, I want this solved. We thought we had this solved at Plumbers last fall. To hear now that we "didn't involve everyone" is disheartening, given that we ("we" being Debian and Ubuntu) were well outnumbered in that room by people from RedHat, Fedora, ChromeOS, and Gentoo.
tbh, i thought the ldso discussion was more "we've been talking about this for a long time, so let's just go with XXX" and then people moved on to the next topic (which was defining exactly what "hard float abi" meant wrt compiler flags). further, it seemed like we had distro representation there, but not mainline gcc people.
So, pretty please, can we (A) address the concerns here without people putting up the "Unique paths are Debian trying to force multi-arch on us" straw man, and (B) agree to *something*, before I ship something that conforms to a standard agreed upon more than half a year ago that is now a cause for contention? Pretty please? With sugar on top? Kthx.
again, saying "/lib/<tuple>/<ldso>" isn't multiarch is bunk. but it sounds like you're fine with /libhf/, so there isn't anything left to thrash about there. -mike
On Mon, Apr 09, 2012 at 07:14:45PM -0400, Mike Frysinger wrote:
again, saying "/lib/<tuple>/<ldso>" isn't multiarch is bunk. but it sounds like you're fine with /libhf/, so there isn't anything left to thrash about there.
I appreciate your careful reading of my email and the issues I outlined, and I look forward to your new urbandictionary definition of the common colloquialism "fine with".
A path for one file isn't multi-arch. A unique path for linkers does help facilitate multi-arch, but we're not forcing you to put libraries some place you don't want to, implement new ideas you don't want to, or any other such "bunk", as you so obviously impartially put it.
I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you.
This isn't about pushing multi-arch on others. This isn't about pushing multi-arch on others. Also, this. Isn't. About. Pushing. Multi-arch. On. Others. I don't know how much more clear I can make that.
If the QT guys filed a bug/feature request on libstdc++ asking to change something that didn't break C++ standards, but facilitated some fancy thing they were working on, my response wouldn't be "dude, I use GTK, what do I care about your weird needs, screw you and your QT agenda", it would be to ask them why they need the thing they need, evaluate how, if in any way, that would impact other users, and work with them.
Using unique linker paths (for new architectures) hurts exactly zero users, and this discussion has taken up FAR MORE developer time than implementation ever would have. Arguing against unique linker paths for the reason that "we've never done that before" is not helpful, and it's blatantly ignoring technical arguments and hiding them behind some bizarre inter-distro conspiracy theory.
Maybe the conspiracy theory is fun for you. I don't know. It's not for me. We were told by GCC upstream that we needed distro consensus. We got that over half a year ago. Now I'm told by distros that the patch not being upstream is why they are backing out of said consensus. Fun.
.... Adam Conrad
On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you.
and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth -mike
On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you.
and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth
Like I said, then, you didn't actually read or understand why proposing multilib paths doesn't work. You realize conceptually, I hope, that there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once you cross the base CPU architecture boundary, right?
Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for us right now, due to sheer luck, and you're running with that as saying that we clearly have no problem here worth solving. When the next architecture clashes with linkers on another (hint: it almost certainly will), do we get to argue about this all over again in six months, instead of codifying a new and saner practice now?
... Adam Conrad
On Tue, Apr 10, 2012 at 05:17:36AM +0000, Adam Conrad wrote:
On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you.
and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth
Like I said, then, you didn't actually read or understand why proposing multilib paths doesn't work. You realize conceptually, I hope, that there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once you cross the base CPU architecture boundary, right?
But you are incorrectly assuming that anyone outside Debian actually sees that as a problem. When we've designed multilib for Linux (following Irix layout, which for some weird reason Debian was the only one which ignored it), it hasn't been a goal and I don't see why it should be a goal now. For crossing base CPU architecture boundaries we have for many years --sysroot, you can't run natively the binaries/libraries anyway, while for ABIs that you can run natively it is very common to run binaries for the different native ABIs concurrently.
We really want consistency about the dynamic linker names etc. across different targets and sneaking silently multiarch paths on one architecture would make it inconsistent with all the others. So, please just use /libhf/ld-linux.so.3.
will), do we get to argue about this all over again in six months, instead of codifying a new and saner practice now?
Not everybody agrees it is a saner practice.
Jakub
On Tue, 10 Apr 2012 07:36:07 +0200 Jakub Jelinek jakub@redhat.com wrote:
We really want consistency about the dynamic linker names etc. across different targets and sneaking silently multiarch paths on one architecture would make it inconsistent with all the others. So, please just use /libhf/ld-linux.so.3.
I personally find /libhf extremely ugly. If having a second path is a problem, how about using the triplet in the filename? Like:
/lib/ld-linux-arm-linux-gnueabihf.so.3
?
Unique per arch and not multiarched. And AFAIK, Linux can handle long filenames just fine...
Konstantinos
On Tue, 10 Apr 2012 12:18:51 +0300 Konstantinos Margaritis konstantinos.margaritis@linaro.org wrote:
On Tue, 10 Apr 2012 07:36:07 +0200 Jakub Jelinek jakub@redhat.com wrote:
We really want consistency about the dynamic linker names etc. across different targets and sneaking silently multiarch paths on one architecture would make it inconsistent with all the others. So, please just use /libhf/ld-linux.so.3.
I personally find /libhf extremely ugly. If having a second path is a problem, how about using the triplet in the filename? Like:
/lib/ld-linux-arm-linux-gnueabihf.so.3
?
Unique per arch and not multiarched. And AFAIK, Linux can handle long filenames just fine...
every distro uses a unique triplet, by putting the triplet in there you then need to get all distros to change to using the same triplets. I personally prefer /libhfp rather than /libhf but I am ok with using either. Any change from /lib would need us to do a mass rebuild. because while not 100% needed I would rather keep libraries with the linker. the changes to rpm to support it would be somewhat minimal. we have stated in Fedora though that we have no intention to support mixing hfp and sfp on the same system. we really do need to ensure consensus for arm64 which I think should be /lib64 for 64 bit arch consistency.
Dennis
On Tue, 10 Apr 2012 09:32:22 -0500 Dennis Gilmore dennis@gilmore.net.au wrote:
every distro uses a unique triplet, by putting the triplet in there you then need to get all distros to change to using the same triplets. I personally prefer /libhfp rather than /libhf but I am ok with using either. Any change from /lib would need us to do a mass rebuild. because while not 100% needed I would rather keep libraries with the linker. the changes to rpm to support it would be somewhat minimal. we have stated in Fedora though that we have no intention to support mixing hfp and sfp on the same system. we really do need to ensure consensus for arm64 which I think should be /lib64 for 64 bit arch consistency.
Ok, I respect that, what about using the actual ABI name, ie aapcs-vfp? or something that includes both the architecture and the eabi, (arm-hardfloat, armhf, armhfp, etc), but *in* the filename (excluding the case of using a separate directory as it's not too popular).
Also, I'm not suggesting changing the triplet or anything, just deciding on a unique name for the triplet. Debian's argument is that the default multilib solution is not future-proof and we would prefer something that is more unique.
Regarding /lib64 for aarch64, that's an entirely different discussion, though I do agree it should be also be resolved sooner rather than later as well.
Regards
Konstantinos
On Tue, Apr 10, 2012 at 09:32:22AM -0500, Dennis Gilmore wrote:
On Tue, 10 Apr 2012 12:18:51 +0300 Konstantinos Margaritis konstantinos.margaritis@linaro.org wrote:
On Tue, 10 Apr 2012 07:36:07 +0200 Jakub Jelinek jakub@redhat.com wrote:
We really want consistency about the dynamic linker names etc. across different targets and sneaking silently multiarch paths on one architecture would make it inconsistent with all the others. So, please just use /libhf/ld-linux.so.3.
I personally find /libhf extremely ugly. If having a second path is a problem, how about using the triplet in the filename? Like:
/lib/ld-linux-arm-linux-gnueabihf.so.3
?
Unique per arch and not multiarched. And AFAIK, Linux can handle long filenames just fine...
every distro uses a unique triplet, by putting the triplet in there you then need to get all distros to change to using the same triplets.
Aargh. Again, use of a standard triplet for arm hard-float was agreed by all parties at the Plumbers' meeting last September. For exactly this reason. Now it seems that a number of people have totally ignored that consensus for the last six months.
I personally prefer /libhfp rather than /libhf but I am ok with using either. Any change from /lib would need us to do a mass rebuild. because while not 100% needed I would rather keep libraries with the linker. the changes to rpm to support it would be somewhat minimal. we have stated in Fedora though that we have no intention to support mixing hfp and sfp on the same system. we really do need to ensure consensus for arm64 which I think should be /lib64 for 64 bit arch consistency.
Precisely who in Redhat/Fedora land has the power to make decisions in this area? We've been clearly wasting our time thus far trying to negotiate agreements about the hard-float platform.
Cheers,
On 04/10/2012 09:37 AM, Steve McIntyre wrote:
Aargh. Again, use of a standard triplet for arm hard-float was agreed by all parties at the Plumbers' meeting last September. For exactly this reason. Now it seems that a number of people have totally ignored that consensus for the last six months.
More correctly, I don't think the ARM community disseminated the substance of that agreement to the GCC and other communities.
I think standardizing the triplet is a no-brainer and independent of whether or not the triplet shows up in the path/name of the dynamic linker. Furthermore, the ARM GCC maintainers have the ability to standardize the triplet without a long debate on the subject.
Jeff
On 04/09/2012 11:17 PM, Adam Conrad wrote:
Like I said, then, you didn't actually read or understand why proposing multilib paths doesn't work. You realize conceptually, I hope, that there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once you cross the base CPU architecture boundary, right?
But what you haven't done is make a case for why anyone should care about this problem.
Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for us right now, due to sheer luck, and you're running with that as saying that we clearly have no problem here worth solving. When the next architecture clashes with linkers on another (hint: it almost certainly will), do we get to argue about this all over again in six months, instead of codifying a new and saner practice now?
My understanding of that architecture is that it's being handled as completely different from it's prior implementations. ie, the toolchain and other things are treating it as an entirely separate architecture even though there is some common lineage to prior implementations.
If the tools are treating this upcoming architecture as a separate and distinct architecture rather than as a variant of a prior architecture, then why do we have to worry about conflicting in the filesystem space?
And just to be clear, I'm not taking sides, merely pointing out that you haven't made the case in this forum in a way that folks understand why this is an important problem.
Jeff
FWIW, my use case for multiarch is not "sharing the root filesystem among multiple systems". It's "sharing the non-lib namespace (/etc, /bin, data) among multiple instruction sets / ABI variants on the same system". I don't need (/usr)?/s?bin to be decorated with a triplet, because the kernel picks a fresh ld.so variant at the execve() boundary; I am happy to mix ARM and x86 binaries (and Python and shell scripts) in /bin, and let the kernel (and binfmt_misc + qemu) sort it out. I only need (/usr)?/lib to be disambiguated *at runtime* because ld.so is not as smart as the kernel. (It's not just ld.so, of course; module/plugin loaders for everything from Python to Firefox have the same problem, and if they don't have the triplet in there somewhere then multiarch breaks them.)
As long as the kernel can find the right ld.so and each ld.so can find its own ld.so.conf, I don't really care where the libraries are put at runtime, as long as I can make it different for each ISA/ABI. However, I do care how much autoconf / pkg-config / debhelper misery I have to go through each time I need to pull in another library dependency. Upstream build machinery can usually accommodate /just/about/anything/lib. Trailing components like lib32, libhf, or lib-gnu-autoconf-triplet are not as consistently trivial.
Personally, I would like for all shared objects to live in (/usr)?/gnu-autoconf-triplet(-extranoise)?/lib, and for the kernel to take responsibility for pointing (/usr)?/lib at an overlay mount containing whatever makes sense for the currently running binary, a la /proc/self. That way I can grandfather in binaries with ABI-ignorant hard-coded library paths, and still handle ISA variants. The "extranoise" might be "neon", or "ssse3", or "android" (so that non-Android binaries on the same system don't see Android-specific libraries with stupidly generic names like libui.so). And the overlay mount is so that I can, if I choose, build the vast majority of my system without NEON instructions (and thus not take the overhead of VFP context save/restore during timeslices that don't use actual floating point) and still use a subset of those libraries from NEON-anointed binaries (assuming I define some sensible way for the kernel to make that distinction).
That isn't necessarily the right solution, of course -- either at a technical level or in the light of the LSB process and other inter-distro politics. But maybe it's at least a more plausible use case for 2012 than NFS-mounting /usr/local on a mix of sun4c, sun4u, and IRIX workstations. (That never did work quite right ...)
Cheers, - Michael
Sorry for the spam. Thunderbird and GMail are not friends today. On Apr 10, 2012 9:46 AM, "Michael Edwards" m.k.edwards@gmail.com wrote:
FWIW, my use case for multiarch is not "sharing the root filesystem among multiple systems". It's "sharing the non-lib namespace (/etc, /bin, data) among multiple instruction sets / ABI variants on the same system". I don't need (/usr)?/s?bin to be decorated with a triplet, because the kernel picks a fresh ld.so variant at the execve() boundary; I am happy to mix ARM and x86 binaries (and Python and shell scripts) in /bin, and let the kernel (and binfmt_misc + qemu) sort it out. I only need (/usr)?/lib to be disambiguated *at runtime* because ld.so is not as smart as the kernel. (It's not just ld.so, of course; module/plugin loaders for everything from Python to Firefox have the same problem, and if they don't have the triplet in there somewhere then multiarch breaks them.)
As long as the kernel can find the right ld.so and each ld.so can find its own ld.so.conf, I don't really care where the libraries are put at runtime, as long as I can make it different for each ISA/ABI. However, I do care how much autoconf / pkg-config / debhelper misery I have to go through each time I need to pull in another library dependency. Upstream build machinery can usually accommodate /just/about/anything/lib. Trailing components like lib32, libhf, or lib-gnu-autoconf-triplet are not as consistently trivial.
Personally, I would like for all shared objects to live in (/usr)?/gnu-autoconf-triplet(-**extranoise)?/lib, and for the kernel to take responsibility for pointing (/usr)?/lib at an overlay mount containing whatever makes sense for the currently running binary, a la /proc/self. That way I can grandfather in binaries with ABI-ignorant hard-coded library paths, and still handle ISA variants. The "extranoise" might be "neon", or "ssse3", or "android" (so that non-Android binaries on the same system don't see Android-specific libraries with stupidly generic names like libui.so). And the overlay mount is so that I can, if I choose, build the vast majority of my system without NEON instructions (and thus not take the overhead of VFP context save/restore during timeslices that don't use actual floating point) and still use a subset of those libraries from NEON-anointed binaries (assuming I define some sensible way for the kernel to make that distinction).
That isn't necessarily the right solution, of course -- either at a technical level or in the light of the LSB process and other inter-distro politics. But maybe it's at least a more plausible use case for 2012 than NFS-mounting /usr/local on a mix of sun4c, sun4u, and IRIX workstations. (That never did work quite right ...)
Cheers,
- Michael
On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
That way I can grandfather in binaries with ABI-ignorant hard-coded library paths, and still handle ISA variants. The "extranoise" might be "neon", or "ssse3"
aren't ISA variants handled already by glibc ? that's what the hwcaps stuff does -- you can put optimized versions in ISA-specific subdirs of the normal lib paths. glibc will look for those first before falling back to the common libs. -mike
On Tue, Apr 10, 2012 at 8:15 PM, Mike Frysinger vapier@gentoo.org wrote:
On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
That way I can grandfather in binaries with ABI-ignorant hard-coded library paths, and still handle ISA variants. The "extranoise" might be "neon", or "ssse3"
aren't ISA variants handled already by glibc ? that's what the hwcaps stuff does -- you can put optimized versions in ISA-specific subdirs of the normal lib paths. glibc will look for those first before falling back to the common libs. -mike
I stand corrected with regard to non-ABI-altering ISA variations -- except for the nightmare that is Bionic libc, which is out of scope for the present discussion. Googling reminds me that Ulrich covered all this ground in his original document for Linaro (which appears to have moved onto the Debian wiki as http://wiki.debian.org/Multiarch/LibraryPathOverview).
So this really is about nothing but freezing the full ABI name (vs. a two-character suffix) into the path to ld.so. And, of course, the implied commitment to resolve any residual ambiguities in the ABI (__cxa_pure_virtual(), anyone?) and to prioritize spec conformance over bug-for-bug compatibility (https://bugs.launchpad.net/gcc-linaro/+bug/952565). When you give something a detailed name, people are more likely to assume that it has a detailed spec, interchangeable among distros and over time. For better or for worse, perpetuating the /lib?? kludge doesn't give that impression.
Cheers, - Michael
On Tuesday 10 April 2012 01:17:36 Adam Conrad wrote:
On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you.
and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth
Like I said, then, you didn't actually read or understand why proposing multilib paths doesn't work. You realize conceptually, I hope, that there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once you cross the base CPU architecture boundary, right?
i don't see this as a problem
Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for us right now, due to sheer luck, and you're running with that as saying that we clearly have no problem here worth solving.
my point was: it works today and has no clashes. that satisfies the "omg we have to ship something $now" and satisfies the requirement that only the Debian people are putting forth (and has already been violated by many targets): the ldso must be unique across all arches/multilibs.
When the next architecture clashes with linkers on another (hint: it almost certainly will), do we get to argue about this all over again in six months, instead of codifying a new and saner practice now?
i don't buy that it'll happen that soon (since ldso's don't get generated quickly), but that is certainly plenty of time for the Debian project to attempt to convince everyone else that multiarch isn't a waste of time. and does so without holding up moving forward with a unified arm hardfloat abi. -mike
On 04/09/2012 05:14 PM, Mike Frysinger wrote:
tbh, i thought the ldso discussion was more "we've been talking about this for a long time, so let's just go with XXX" and then people moved on to the next topic (which was defining exactly what "hard float abi" meant wrt compiler flags). further, it seemed like we had distro representation there, but not mainline gcc people.
Actually Mike, there was at least one mainline GCC person there. Me. Of course I was thrown into a discussion I knew nothing about, but the goal of having a standardized path to discover ld.so which worked across distros seems like goodness to me. Honestly, I don't see what all the resistance is about.
Jeff
On Tuesday 10 April 2012 00:16:34 Jeff Law wrote:
On 04/09/2012 05:14 PM, Mike Frysinger wrote:
tbh, i thought the ldso discussion was more "we've been talking about this for a long time, so let's just go with XXX" and then people moved on to the next topic (which was defining exactly what "hard float abi" meant wrt compiler flags). further, it seemed like we had distro representation there, but not mainline gcc people.
Actually Mike, there was at least one mainline GCC person there. Me.
my mistake. i don't think we've met before, and that was a fairly busy time for me, so i probably missed things. we should get a beer ;).
Of course I was thrown into a discussion I knew nothing about
admittedly, that was the first time i've been in a linaro-related meeting before, and i hadn't been following linaro at all before (as the job i left before wasn't working on arm at all)
goal of having a standardized path to discover ld.so which worked across distros seems like goodness to me. Honestly, I don't see what all the resistance is about.
i think we have suggestions that would work for everyone ... but maybe this thread has gotten too big so we need to regroup with a summary -mike
Em 9 de abril de 2012 17:48, Adam Conrad adconrad@debian.org escreveu:
On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
On 4 April 2012 18:54, Jakub Jelinek jakub@redhat.com wrote:
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc
OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think.
The problem here that everyone !Debian isn't taking into account is that multilib paths don't solve our use-case. Multilib paths only solve the case of multiple ABIs on the same base processor family. As soon as you combine x86, arm, power, etc, you end up with overlaps (or, the potential for overlaps; the fact that various arches accidentally have different majors keeps those overlaps to a minimum right now, but that's not by design).
Honestly, this is something we should have solved two decades ago, but the very idea that someone would want to do what Debian is now doing didn't occur to any of us. That's cool. We didn't think of it back then. That's no excuse to continue with the status quo just because it's the status quo.
To be perfectly clear here, we don't care where the linker goes (really, we don't), we just want it to be both arch and ABI unique. If that means taking a crc32 of a rot-13 of the compiler flags used to define the ABI, and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it.
If this means setting up a (very) lightweight process with the LSB, where everytime a new distro proposes a shiny new arch/ABI, they submit it, and the LSB assigns them an ABI serial, and we all then agree to toss the linker in /lib/abi-00002345/ld-linux, that works too. Don't care. Really don't care.
This isn't about trying to force people to switch from multilib to multi- arch, where the former is clearly working fine for them. It's not. This is purely about people bikeshedding about paths they consider un-pretty, while (I hope not maliciously or knowingly?) causing potential overlap and breakage for those of us for whom this actually matters and isn't purely a color selection exercise.
In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for us, purely because that doesn't overlap with any other linkers that Debian currently ships. The fact that the multilib path happens to work doesn't make it correct for our use-case, and certainly doesn't make it correct ongoing.
Ultimately, however, I want this solved. We thought we had this solved at Plumbers last fall. To hear now that we "didn't involve everyone" is disheartening, given that we ("we" being Debian and Ubuntu) were well outnumbered in that room by people from RedHat, Fedora, ChromeOS, and Gentoo. We all agreed on something back then, and now that I'm three weeks away from shipping an armhf distro, it's all exploded yet again into Bikeshed Part III: The Revenge of Purple Paint.
I really want to ship a compiler than stuffs the "correct" and agreed upon linker in headers. I don't want to see third parties build binaries on Ubuntu that don't run on Fedora. No one wants to see that, I think.
Obviously, conversely (though this is much less hassle), I need to be able to ship a linker symlink that matches expectations, so that binaries built on Fedora will run on Ubuntu. Again, I'm sure we all want that.
So, pretty please, can we (A) address the concerns here without people putting up the "Unique paths are Debian trying to force multi-arch on us" straw man, and (B) agree to *something*, before I ship something that conforms to a standard agreed upon more than half a year ago that is now a cause for contention? Pretty please? With sugar on top? Kthx.
(of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only.
I expect that most distros will probably ship their aarch64 libraries in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent with their other 64-bit ports, but where you put libraries is entirely unrelated to where the linker lives. You could have all your libraries in /root/.trash/ and if the linker lives in a canonical location and can resolve that, that's fine. I will still (obviously, I think, from my comments above) argue that the linker should live in a guaranteed unique location. Overlap with other arches in /lib64 is certainly far more likely than overlap in /libhf.
Not trying to criticize, just attempt to show my view of the subject. What I understand of Debian multiarch is the desire to be able to: 1. Mount the root directory from a file server in different computers. 1.1. Computers share user home directories, can see binaries of other architectures, and can share "noarch" files, as that would be a bug if such files were wordsize or byte order dependent. 2. Boot different kernels (linux, freebsd, etc) and be able to have things just working. One kernel may even run binaries targeted to the other as they are the same architecture, a U*X is a U*X, or close enough.
Last time I looked at Debian wiki, there was not yet a defined plan for bin/x-y-z/ paths, so, I understand this is an "incremental" work in progress, and first goal is to install close enough binaries together, e.g. run a X Server and drivers built for one ABI and client applications built for another. Having firefox for one abi, and all of gtk, and a myriad of loadable modules for another can be painful to maintain... Applications that link to different ABI libGL looks like a possible common case. Talking about lib*GL, I believe this is one of the main reasons of hardfp arm, and only when passing lots of float/double by value from different DSOs. Other reason is that newer arm C compiler will support only software float or hardware float with hardfp abi, but enough about it :-)
For the sake of a example, TeXLive ships mostly "noarch" files, and pre built, statically linked binaries are installed in bin/dir with "dir" being one of:
alpha-linux amd64-freebsd amd64-kfreebsd i386-cygwin i386-freebsd i386-kfreebsd i386-linux i386-netbsd i386-solaris mips-irix powerpc-aix powerpc-linux sparc-linux sparc-solaris universal-darwin win32 x86_64-darwin x86_64-linux x86_64-solaris
... Adam Conrad
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
Thanks, Paulo
El Wed, 4 Apr 2012 08:54:12 +0200 Jakub Jelinek jakub@redhat.com escribió:
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those that choose the Debian layout instead, if it is added somehow configurable into upstream gcc/glibc of course handle it similarly there. I just wonder why that hasn't been done 10 years ago and only needs doing now (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
Fedora at least plans to not support installing hfp and sfp on the same system, while not completely decided I don't think we will be supporting running 32 bit arm binaries on 64 bit arm. there is not a legacy support use case that I can think of i.e. existing common proprietary software. Though I imagine that we will use /lib64 for consistency with existing 64 bit arches.
Dennis
On 05/04/12 14:34, Dennis Gilmore wrote:
Fedora at least plans to not support installing hfp and sfp on the same system, while not completely decided I don't think we will be supporting running 32 bit arm binaries on 64 bit arm. there is not a legacy support use case that I can think of i.e. existing common proprietary software. Though I imagine that we will use /lib64 for consistency with existing 64 bit arches.
Regardless of what Fedora wants to support in its own environments, it's important that what they do doesn't prevent other distros from supporting multiple flavours if they so wish. That means that there must be at least common agreement on the fundamental naming of the dynamic loader (assuming that the libraries themselves can be found via some config magic).
R.
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
2012/4/4 Paulo César Pereira de Andrade
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
We've previously discussed changing the name or the version number of the linker, but there was a worry that compatibility would be broken. Apparently the Meego folks have released a hard-float system using ld-linux.so.3 and were concerned about this.
Cheers,
On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
2012/4/4 Paulo César Pereira de Andrade
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
We've previously discussed changing the name or the version number of the linker, but there was a worry that compatibility would be broken. Apparently the Meego folks have released a hard-float system using ld-linux.so.3 and were concerned about this.
i'm not sure how changing the leading dir components but leaving the base path the same would be any more or less work for meego to maintain backwards compatibility. whatever random path is picked, they're going to be broken, as the ELF encodes the full path to the ldso. -mike
Em 5 de abril de 2012 12:09, Mike Frysinger vapier@gentoo.org escreveu:
On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
2012/4/4 Paulo César Pereira de Andrade
I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be "good to have" to be able to run binaries for either without resorting to a chroot, and only testing purposes.
Bumping major or calling it ld-linux-foo.so.3 is out of question?
I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part.
We've previously discussed changing the name or the version number of the linker, but there was a worry that compatibility would be broken. Apparently the Meego folks have released a hard-float system using ld-linux.so.3 and were concerned about this.
i'm not sure how changing the leading dir components but leaving the base path the same would be any more or less work for meego to maintain backwards compatibility. whatever random path is picked, they're going to be broken, as the ELF encodes the full path to the ldso. -mike
I guess now it is too late to defer --with-float=hard for 64 bit armv8, but besides possibly tedious, full rebuilds of, (hopefully) yet to be released hardfp distros per se is not a bad thing.
My suggestion for lib$color is $color == vfp (one could choose neon :-), and then it is a distro choice if using /lib as software float to be able to install the same binaries on armv4+, or build with vfp but use software float abi so that armv4+ binaries work.
Major issue IMO is that things are being done thinking too much on the now, so, hardfp is good to support nvidia drivers, and plain soft float (armv5) is good for raspberry pi...
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
Paulo
On Wed, Apr 04, 2012 at 01:11:33AM +0200, Jakub Jelinek wrote:
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros.
This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad.
I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64.
(cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that)
I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things.
Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine.
That's been discussed previously, yes. While technically quite feasible in terms of code, there's enough potential for confusion that we though it was just simpler to use two different linker binaries.
Cheers,
-
Adam Conrad -
Dennis Gilmore -
Jakub Jelinek -
Jeff Law -
Joseph S. Myers -
Konstantinos Margaritis -
Michael Edwards -
Michael Hope -
Michael K. Edwards
-
Mike Frysinger -
Paulo César Pereira de Andrade -
Peter Robinson -
Richard Earnshaw -
Steve McIntyre