On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
On 04/10/2012 04:42 AM, Steve McIntyre wrote:
It's one of the things we're trying to achieve with multi-arch. We can support mixed-ABI, mixed-OS, mixed-architecture environments cleanly on one system, using a consistent set of packages for all. Setting up a cross-compilation environment suddenly becomes easy - install the cross-compiler and the libs for the target platform straight from a normal Debian mirror as binary packages.
See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more rationale.
I've read it and still don't see the benefit, particularly as it relates to mixed instruction sets. Or more precisely, I don't see the value in supporting mixed instruction sets. Once you drop the mixed instruction set argument I think the whole argument for embedding the target triplet into the dynamic linker pathname falls apart.
We see a value in supporting mixed instruction sets for two cases: emulation and cross-building. If you don't want or care so much about those, then fine - that's your call in your environment. They're both cases that Debian/Ubuntu would like to do a much better job of supporting in future, using existing packages instead of having to do so much special-casing all over. I hope that you (plural) can understand/accept that?
We have to agree on a standard path if we're ever going to have working cross-distro binaries, and that's increasingly important to us in the ARM world. By all means ignore the multi-arch route that the Debian world is following, but please accept our reasoning for the linker location.
But the entire reason behind the need to embed the triplet into the dynamic linker's path is the debian multi-arch stuff AFAICT. I think that's what many folks are complaining about.
I realize the goal here is to allow a single binary to run on multiple systems and I think that's a worthy goal.
Cool. :-)
Cheers,