Hi Folks,
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
Jon.
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
these are the forms that were committed to the GNU config project, so the ship has already sailed -mike
On 09/10/2012 03:39 PM, Mike Frysinger wrote:
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
these are the forms that were committed to the GNU config project, so the ship has already sailed
Right. That /ought/ to be the case. I'm sending this just so that somebody doesn't decide that even though these are the triplets they feel like doing something completely different - maybe multi-libarch-with-a-twist-of-lime-because-its-monday, or whatever :)
Jon.
On Mon, Sep 10, 2012 at 03:39:20PM -0400, Mike Frysinger wrote:
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
In discussions with various folks, it seems that none of the distros are particularly interested in BE. \o/
these are the forms that were committed to the GNU config project, so the ship has already sailed
Yup, definitely.
Cheers,
On Thu, Sep 13, 2012 at 9:33 AM, Steve McIntyre wrote:
On Mon, Sep 10, 2012 at 03:39:20PM -0400, Mike Frysinger wrote:
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
In discussions with various folks, it seems that none of the distros are particularly interested in BE. \o/
i was just more nettling Jon ;)
if hardware ever materializes, then it'd be easy to do Gentoo. but if there's a lack of hardware, we certainly won't waste time on theoretical stuff. -mike
On 09/13/2012 01:24 PM, Mike Frysinger wrote:
On Thu, Sep 13, 2012 at 9:33 AM, Steve McIntyre wrote:
On Mon, Sep 10, 2012 at 03:39:20PM -0400, Mike Frysinger wrote:
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
In discussions with various folks, it seems that none of the distros are particularly interested in BE. \o/
i was just more nettling Jon ;)
Always fun. Note that just because we agree on the triplet, doesn't mean that we've yet had the fun of discussing the linker path until we pass out form sheer exhaustion. So, let's have that one out before some of us go doing our own thing. From my point of view, we don't care /at all/ about multi-arch and certainly I have no plans of even supporting a 32-bit ARM userspace on AArch64 (if you want that, use virtualization). Sure, the latter is aspirational and someone will ruin it, so maybe we need to go to /lib64 rather than /lib (I don't want to). But just because I don't like multi-arch doesn't mean we shouldn't know if Debian/Ubuntu are going to do a different linker path again? :)
In other words, I can live with whatever, but let's do it one way the first time, rather than repeating what happened with ARMv7. So, what are Debian and Ubuntu going to do for multi-archification of AArch64?
if hardware ever materializes, then it'd be easy to do Gentoo. but if there's a lack of hardware, we certainly won't waste time on theoretical stuff.
That's cool. I'll not comment on hardware except to say I don't think it will be theoretical for all that long, if it even is now.
Jon.
On 09/16/2012 09:34 PM, Jon Masters wrote:
In other words, I can live with whatever, but let's do it one way the first time, rather than repeating what happened with ARMv7. So, what are Debian and Ubuntu going to do for multi-archification of AArch64?
Asking because I'm tracking all of the Launchpad tasks assigned on AArch64 bootstrap, so I know this is something being considered.
Jon.
+++ Jon Masters [2012-09-16 21:34 -0400]:
On 09/13/2012 01:24 PM, Mike Frysinger wrote:
On Thu, Sep 13, 2012 at 9:33 AM, Steve McIntyre wrote:
On Mon, Sep 10, 2012 at 03:39:20PM -0400, Mike Frysinger wrote:
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
In discussions with various folks, it seems that none of the distros are particularly interested in BE. \o/
i was just more nettling Jon ;)
Always fun. Note that just because we agree on the triplet, doesn't mean that we've yet had the fun of discussing the linker path until we pass out form sheer exhaustion. So, let's have that one out before some of us go doing our own thing. From my point of view, we don't care /at all/ about multi-arch and certainly I have no plans of even supporting a 32-bit ARM userspace on AArch64 (if you want that, use virtualization). Sure, the latter is aspirational and someone will ruin it, so maybe we need to go to /lib64 rather than /lib (I don't want to).
Or do it properly with multiarch: :-) /lib/aarch64-linux-gnu /lib/arm-linux-gnueabihf
But just because I don't like multi-arch doesn't mean we shouldn't know if Debian/Ubuntu are going to do a different linker path again? :)
In other words, I can live with whatever, but let's do it one way the first time, rather than repeating what happened with ARMv7. So, what are Debian and Ubuntu going to do for multi-archification of AArch64?
Multi-arch support and libc linker/loader path are mostly independent. All that is needed is that the linker path for each ABI is unique (and agreed).
The original aarch64 work was all done using a multi-arch style linker path, just for consistency: /lib/aarch64-linux-gnu/ld.so.1
But as that has proved unpopular with upstream, the patches which I believe are imminent upstream have used /lib/ld-linux-aarch64.so.1 and /lib/ld-linux-aarch64_be.so.1 to be consistent with what was thrashed out recently as acceptable to everbody on this list and in telcons.
Debian and Ubuntu (and other derivatives) will use "aarch64-linux-gnu" (ie the same as the gnu triplet) for the multiarch tuple, so libraries will be in /lib/aarch64-linux-gnu and /usr/lib/aarch64-linux-gnu
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
Now, I'm in agreement with Jon, and would much prefer to see them in /lib, but I was outvoted :-)
The focus currently is on upstreaming architecture support _without_ having to also have a big fight about the benefits or otherwise of multiarch.
Personally I think that's a mistake and we'll just be stuck with the limited 'lib64' hack for another 10 years, at least outside Debian-world, but ultimately if that's what most libc/toolchain maintainers still want then we can all live with that (at the expense of significant divergence between library paths used in distros, but that's been true for a decade already and we all survived).
If we could agree on world where you could build for _either_ a single-ABI world (everything in /lib), _or_ a multiarch world (everything in /lib/<tuple>) that would make a lot of sense to me. The current options of '64/32 only multilib-style multiarch' or 'proper multiarch' seems suboptimal.
So the short answer is that currently the aarch64 patches are totally un-multiarch, and fit in with current agreed upstream practice. So if you think multiarch is nonsense, and multilib is just fine, say nothing and all will be hunky-dory :-)
If you prefer /lib over /lib64 or /lib/<ABI-tuple> over /lib64 then now would be a good time to speak up.
This bikeshed isn't finished yet.
Wookey
On 17 September 2012 13:24, Wookey wookey@wookware.org wrote:
* lots of discussion*
This bikeshed isn't finished yet.
Let me finish it then:
1. We use whatever comes in the upstream patches. 2. EOD
On Monday 17 September 2012 07:18:21 Riku Voipio wrote:
On 17 September 2012 13:24, Wookey wookey@wookware.org wrote:
- lots of discussion*
This bikeshed isn't finished yet.
Let me finish it then:
- We use whatever comes in the upstream patches.
- EOD
yeah, it seems to me the topic has already been settled. upstream is using: /lib/ld-linux-aarch64.so.1 -mike
On 09/17/2012 01:45 PM, Mike Frysinger wrote:
On Monday 17 September 2012 07:18:21 Riku Voipio wrote:
On 17 September 2012 13:24, Wookey wookey@wookware.org wrote:
- lots of discussion*
This bikeshed isn't finished yet.
Let me finish it then:
- We use whatever comes in the upstream patches.
- EOD
yeah, it seems to me the topic has already been settled. upstream is using: /lib/ld-linux-aarch64.so.1
I'm happy with that, so that's what we'll use. I just want to make sure we all are doing exactly the same thing. Once we get the distros boostrapped, we'll need to get onto other stuff like LSB and ensure we have a really solid binary compatibility story where we can for v8.
Jon.
On 09/17/2012 06:24 AM, Wookey wrote:
+++ Jon Masters [2012-09-16 21:34 -0400]:
On 09/13/2012 01:24 PM, Mike Frysinger wrote:
On Thu, Sep 13, 2012 at 9:33 AM, Steve McIntyre wrote:
On Mon, Sep 10, 2012 at 03:39:20PM -0400, Mike Frysinger wrote:
On Mon, Sep 10, 2012 at 2:56 PM, Jon Masters wrote:
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there now because I don't want another ARMv7 experience later :)
unless you're doing big endian then it's: aarch64_be-linux-gnu
In discussions with various folks, it seems that none of the distros are particularly interested in BE. \o/
i was just more nettling Jon ;)
Always fun. Note that just because we agree on the triplet, doesn't mean that we've yet had the fun of discussing the linker path until we pass out form sheer exhaustion. So, let's have that one out before some of us go doing our own thing. From my point of view, we don't care /at all/ about multi-arch and certainly I have no plans of even supporting a 32-bit ARM userspace on AArch64 (if you want that, use virtualization). Sure, the latter is aspirational and someone will ruin it, so maybe we need to go to /lib64 rather than /lib (I don't want to).
Or do it properly with multiarch: :-) /lib/aarch64-linux-gnu /lib/arm-linux-gnueabihf
Forgive my sarcasm. Perhaps not everyone sees I'm just messing with you over the multi-arch thing. To each his own as long as we agree on the linker path :) Thanks for the informative response Wookey :)
Jon.
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
Jon.
On Wednesday 14 November 2012 22:49:06 Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
in terms of binary compatibility, i don't think paths beyond the ldso matter. when glibc is configured, you give it the lib paths to use, and then at runtime you can add more stuff to /etc/ld.so.conf. that means distros can use whatever conventions they want as the ldso interp gates it all, and compiled ELF applications only have that ldso path encoded in them. -mike
On Thu, Nov 15, 2012 at 12:51:01AM -0500, Mike Frysinger wrote:
On Wednesday 14 November 2012 22:49:06 Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
in terms of binary compatibility, i don't think paths beyond the ldso matter. when glibc is configured, you give it the lib paths to use, and then at runtime you can add more stuff to /etc/ld.so.conf. that means distros can use whatever conventions they want as the ldso interp gates it all, and compiled ELF applications only have that ldso path encoded in them.
Mostly yes, but consider apps which include plugins too. :-/
Cheers,
On Thursday 15 November 2012 07:07:17 Steve McIntyre wrote:
On Thu, Nov 15, 2012 at 12:51:01AM -0500, Mike Frysinger wrote:
On Wednesday 14 November 2012 22:49:06 Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
in terms of binary compatibility, i don't think paths beyond the ldso matter. when glibc is configured, you give it the lib paths to use, and then at runtime you can add more stuff to /etc/ld.so.conf. that means distros can use whatever conventions they want as the ldso interp gates it all, and compiled ELF applications only have that ldso path encoded in them.
Mostly yes, but consider apps which include plugins too. :-/
with encoded rpaths, i'm not sure you'll get cross-distro convergence on that anytime soon. as an example, kde/qt get parallel installed in different ways: some use /opt, some use /usr/<kde|qt><ver>, some use /usr/<os-multilib>/<kde| qt><ver>. maybe there are even others i haven't seen.
similarly, you have internal helper paths encoded and here we have /libexec/, /usr/libexec/, /usr/lib/<package-name|misc>/, /usr/<os-muliblib>/<package- name|misc>/, and maybe other craziness.
aarch64's behavior (use lib64) is nothing new to the multilib scene (x86_64, mips n64, s390x, ppc64), and distros have handled it thus far. i don't think we need to hold aarch64 hostage here to much larger/ugly issues that are not as common. -mike
On Thu, Nov 15, 2012 at 02:14:22PM -0500, Mike Frysinger wrote:
On Thursday 15 November 2012 07:07:17 Steve McIntyre wrote:
Mostly yes, but consider apps which include plugins too. :-/
with encoded rpaths, i'm not sure you'll get cross-distro convergence on that anytime soon. as an example, kde/qt get parallel installed in different ways: some use /opt, some use /usr/<kde|qt><ver>, some use /usr/<os-multilib>/<kde| qt><ver>. maybe there are even others i haven't seen.
similarly, you have internal helper paths encoded and here we have /libexec/, /usr/libexec/, /usr/lib/<package-name|misc>/, /usr/<os-muliblib>/<package- name|misc>/, and maybe other craziness.
aarch64's behavior (use lib64) is nothing new to the multilib scene (x86_64, mips n64, s390x, ppc64), and distros have handled it thus far. i don't think we need to hold aarch64 hostage here to much larger/ugly issues that are not as common.
Oh, agreed 100% :-)
Cheers,
On Wed, Nov 14, 2012 at 10:49:06PM -0500, Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
Those symlinks have been included in Debian for ages for amd64, so they'll be there for AArch64 too.
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Thu, 15 Nov 2012 12:06:20 +0000 Steve McIntyre steve.mcintyre@linaro.org escribió:
On Wed, Nov 14, 2012 at 10:49:06PM -0500, Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
Those symlinks have been included in Debian for ages for amd64, so they'll be there for AArch64 too.
Cheers,
so the question i see right now is where is the linker to be located on the system? I personally think that it should go in /lib64/ and before anyone gets to far in bootstrapping we should fix it upstream to be located there. Does anyone disagree?
Dennis
On 11/19/2012 09:29 PM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Thu, 15 Nov 2012 12:06:20 +0000 Steve McIntyre steve.mcintyre@linaro.org escribió:
On Wed, Nov 14, 2012 at 10:49:06PM -0500, Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
Those symlinks have been included in Debian for ages for amd64, so they'll be there for AArch64 too.
so the question i see right now is where is the linker to be located on the system? I personally think that it should go in /lib64/ and before anyone gets to far in bootstrapping we should fix it upstream to be located there. Does anyone disagree?
Hi Dennis,
I know we talked about this earlier, and I understand your concerns, but I think it is too late for this discussion. The upstream patches are already using /lib, and several distributions have already picked up that location. The path includes (specifically) the architecture in the path name component, so it won't interfere if someone did want to make a 32-bit mutli-lib arrangement in /lib with 64-bit in /lib64.
The only reason for making a change at this time appears to be cosmetic, for removing /lib for example. I can understand that, and if we were discussing this a year ago (or even months ago when I first raised it on this list), then it might be a reasonable change, but at this time I cannot find an overwhelming technical justification.
Going forward, we do need to solve these problems between the different distributions by having actual standardization bodies and - shock - a general willingness to engage on these things much earlier (not just with ARM). My personal prediction there is "good luck" and that it'll never happen, but it would be a nice Utopia if we can ever get there before our differentiation ultimately repeats the 80s/90s Wars again.
Jon.
On Tuesday 20 November 2012 03:25:56 Jon Masters wrote:
The only reason for making a change at this time appears to be cosmetic, for removing /lib for example. I can understand that, and if we were discussing this a year ago (or even months ago when I first raised it on this list), then it might be a reasonable change, but at this time I cannot find an overwhelming technical justification.
i don't think removal of /lib/ is really feasible. that's the path that gets used for firmware (/lib/firmware/) and kernel modules (/lib/modules/<kver>/) regardless of the default ABI on the system.
similarly, userspace packages are using that path for supplemental files like the bootloader (grub) or ABI-independent settings (udev rules). -mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Tue, 20 Nov 2012 03:25:56 -0500 Jon Masters jonathan@jonmasters.org escribió:
On 11/19/2012 09:29 PM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Thu, 15 Nov 2012 12:06:20 +0000 Steve McIntyre steve.mcintyre@linaro.org escribió:
On Wed, Nov 14, 2012 at 10:49:06PM -0500, Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
Those symlinks have been included in Debian for ages for amd64, so they'll be there for AArch64 too.
so the question i see right now is where is the linker to be located on the system? I personally think that it should go in /lib64/ and before anyone gets to far in bootstrapping we should fix it upstream to be located there. Does anyone disagree?
Hi Dennis,
I know we talked about this earlier, and I understand your concerns, but I think it is too late for this discussion. The upstream patches are already using /lib, and several distributions have already picked up that location. The path includes (specifically) the architecture in the path name component, so it won't interfere if someone did want to make a 32-bit mutli-lib arrangement in /lib with 64-bit in /lib64.
The only reason for making a change at this time appears to be cosmetic, for removing /lib for example. I can understand that, and if we were discussing this a year ago (or even months ago when I first raised it on this list), then it might be a reasonable change, but at this time I cannot find an overwhelming technical justification.
It has absolutely nothing to do with removing /lib thats not possible it has to do with compatability and consistency with other 64 bit arches. x86_64 sparc64 ppc64 all put the linker in /lib64
Dennis
On 11/20/2012 09:07 PM, Dennis Gilmore wrote:
<snip lib vs. /lib64 discussion>
It has absolutely nothing to do with removing /lib thats not possible
What I was saying, if I may, is that I understand a desire to have a /lib-free system in terms of no content having to be in there. As things stand, the only thing required to be in there on AArch64 is the dynamic linker, per the upstream patch posting. The path name is unique enough that a similar clash to what happened in ARMv7 with the multi-arch and non-multi-arch conflicts should not be an issue.
it has to do with compatability
This is why I raised the issue months ago. However, the decision to place the dynamic linker in /lib was made, and everyone is going to use that (thus preserving compatibility). Unfortunately, some distros will use "multi-arch" and some will not but it should be ok as long as we share the linker. The choice of /lib or /lib64 for the dynamic linker is disjoint from the issues related to other library locations.
We don't get to make this choice alone. Sure, if it were just Fedora then let's go ahead and use whatever we like. But I did ask what the path would be, and I was told that it would be /lib. In the absence of any real standardization body remaining in this world to have these things go through, we'll have to live with that on our end.
and consistency with other 64 bit arches. x86_64 sparc64 ppc64 all put the linker in /lib64
This I understand. However, again, we don't get to make that call. The call has already been made as part of the patch submissions, and unless everyone is very keen to switch, I think we'll live with it. I'm not actually trying to argue with you :) Just saying whether or not we happen to like the choice that has been made may make little difference if everyone is happily using the existing path (and may cause more harm in changing it vs. leaving it as it is).
Jon.
On Tuesday 20 November 2012 21:07:48 Dennis Gilmore wrote:
El Tue, 20 Nov 2012 03:25:56 -0500 Jon Masters escribió:
On 11/19/2012 09:29 PM, Dennis Gilmore wrote:
El Thu, 15 Nov 2012 12:06:20 +0000 Steve McIntyre escribió:
On Wed, Nov 14, 2012 at 10:49:06PM -0500, Jon Masters wrote:
On 09/17/2012 06:24 AM, Wookey wrote:
The upstream patches have used the existing (poor man's multiarch) paths: /lib64 /usr/lib64 in order to make them fit in with existing upstream convention.
I originally wanted to use /lib, but we're going to switch to /lib64 for consistency with other 64-bit architectures, and so on. I am concerned that we agree on the linker, but not on other library paths. Will Debian and Ubuntu consider a package that includes /lib64 "compatibility" symlinks so that non-multiarch systems can share code with multi-arch ones? We don't need to break this :)
Those symlinks have been included in Debian for ages for amd64, so they'll be there for AArch64 too.
so the question i see right now is where is the linker to be located on the system? I personally think that it should go in /lib64/ and before anyone gets to far in bootstrapping we should fix it upstream to be located there. Does anyone disagree?
I know we talked about this earlier, and I understand your concerns, but I think it is too late for this discussion. The upstream patches are already using /lib, and several distributions have already picked up that location. The path includes (specifically) the architecture in the path name component, so it won't interfere if someone did want to make a 32-bit mutli-lib arrangement in /lib with 64-bit in /lib64.
The only reason for making a change at this time appears to be cosmetic, for removing /lib for example. I can understand that, and if we were discussing this a year ago (or even months ago when I first raised it on this list), then it might be a reasonable change, but at this time I cannot find an overwhelming technical justification.
It has absolutely nothing to do with removing /lib thats not possible it has to do with compatability and consistency with other 64 bit arches. x86_64 sparc64 ppc64 all put the linker in /lib64
that's actually not true. s390x uses /lib/ld64.so.1. to a lesser degree, uClibc's 64bit is usually in /lib/ as well. -mike
-
Dennis Gilmore -
Jon Masters -
Jon Masters -
Mike Frysinger -
Riku Voipio -
Steve McIntyre -
Wookey