+++ 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