Re: Armhf dynamic linker path
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
2012.04 release prep
Hi there. The 2012.04 toolchain release is this week. Ulrich, I see your fix for LP: #968766 has been approved upstream. In theory it's too late but I'm happy to land it if you are. Could you decide and let Andrew know by the middle of Tuesday? Andrew, if you don't hear from Ulrich then spin away. Andrew, could you run the release process on Tuesday please? There's one extra step this month: once you've uploaded and spawned the job, go to the scheduler screen and click on 'Release' beside each of the ursas. I reserved them to make sure they'd be idle and ready to pick up the release build when ready. Thiago, let us know if Ulrich or I can lend a hand with the GDB release. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On Monday 09 April 2012 15:47:56 Adam Conrad wrote: > are you not just as much hindering Debian over nothing more than a path to a > single file? nope. sounds more like self inflicted pain. > 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. no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem". -mike signature.asc Description: This is a digitally signed message part. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On 04/09/2012 10:19 PM, Mike Frysinger wrote: On Monday 09 April 2012 15:47:56 Adam Conrad wrote: are you not just as much hindering Debian over nothing more than a path to a single file? nope. sounds more like self inflicted pain. 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. no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem". Don't the multilib paths contain enough information to handle this? They certainly have in the past as I can recall building toolchains that handled several architectures within power, arm & mips families in the past Is the problem here that glibc simply isn't building multilib paths in the same way that GCC has for the last 15 years? jeff ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On Tuesday 10 April 2012 00:23:09 Jeff Law wrote: > On 04/09/2012 10:19 PM, Mike Frysinger wrote: > > On Monday 09 April 2012 15:47:56 Adam Conrad wrote: > >> 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. > > > > no one is saying it can (or at least, i'm certainly not). my point is > > that many people don't see this as a "problem". > > Don't the multilib paths contain enough information to handle this? > They certainly have in the past as I can recall building toolchains that > handled several architectures within power, arm & mips families in the past his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions. > Is the problem here that glibc simply isn't building multilib paths in > the same way that GCC has for the last 15 years? afaik, glibc and gcc should be in sync ... can't say i've noticed issues with all the arches Gentoo supports. -mike signature.asc Description: This is a digitally signed message part. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
