Armhf dynamic linker path
adconrad at debian.org
Mon Apr 9 19:47:56 UTC 2012
On Wed, Apr 04, 2012 at 11:11:30PM -0400, Mike Frysinger wrote:
> On Wednesday 04 April 2012 22:48:34 Wookey wrote:
> > Mike Frysinger [2012-04-02 19:56 -0400]:
> trying to paint the use of a triplet in the path as any other than multiarch
> is bunk. as Joseph explained in detail, there already is a standard in
> mainline tools. if you want to change the standard, then propose something
> consistently for everyone. backdooring it for 1 target is not the way.
It's not readily changable for all targets, and you know that (or, at least,
I hope you know that?). As Jeff Law said at Plumbers (where there were Gentoo
people sitting in as well, whose opinion was "Gentoo doesn't care, do whatever),
"This is something we should have been doing for the last twenty years".
I appreciate that it's irksome to have to deal with Debian's terrible and
unreasonable desire to install more than one base architecture at the same
time, but while you accuse us of "backdooring" (we intentionally brough people
together to discuss this, repeatedly), are you not just as much hindering
Debian over nothing more than a path to a single file?
To be very, very, very clea here. multilib can not solve the "different base
arches on one system problem". lib/lib32/lib64/libhf/libsf will overlap as
soon as you have more than one of x86, arm, power, mips, etc.
To be extra clear, we're NOT asking people to implement multiarch. We'd like
that to happen some day, but this isn't some "slippery slope", this is the
path to ONE file. One. In Debian, we currently have that path (for, say,
x86_64) in locations we'd no prefer. We don't argue with the world that it's
ugly, we just place the linker where everyone else does.
In the armhf case, given that very few of us were shipping armhf, and only
some of us had really bootstrapped an archive worth talking about, we felt
that we could discuss this last year and reach a consensus. And we did. At
least, we did until it got bikeshedded to death more than six months later.
I'll agree with you that Debian's multiarch doesn't account for every possible
ABI, as it only accounts for (oddly enough), the ones that they ship. This
could be fixed.
I'll also agree that having the linker in an ABI-unqiue (including arch-unique,
which multilib CAN NOT provide) path would be ideal, though we all know that
i386 and x86_64 will probably end up carrying compat symlinks for years to
deal with all the commercial software. Thankfully, most non-x86 ports could
actually just hard-switch and carry on with it.
Again (and again, and again), this isn't about Debian trying to push multi-
arch on people, it's about having a linker path that works for everyone. The
proposed /lib/(arbitrary-unique-name)/ld-linux make it work for everyone, but
some say it's "ugly" or "unsightly", or downright backdoorish. The proposed
"keep with the status quo and use multilib paths" works for some people, but
not others. If that's the route we have to take, we'll take it, and live with
the happy accident that /libhf/ld-linux.so.3 happens to not overlap with any
arch most people care about right now, but that happy accident doesn't make
it the sane ongoing solution. I'm sure people can take a step back and see
that without it being some "us versus them" argument.
More information about the linaro-toolchain