On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
On 4 April 2012 18:54, Jakub Jelinek ja...@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-2345/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
