+++ 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 -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
