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. ... Adam _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
