Em 11 de abril de 2012 10:04, Steve McIntyre steve.mcintyre@linaro.org escreveu:
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?
Probably beating a dead cow, but, the major problem with sysroots would be the triplet name?
E.g, in any architecture:
/arm-linux-gnueabi/sysroot-contents-here
and ld.so living in
/arm-linux-gnueabi/lib/ld.so.3
and arch specific package cross toolchain in:
/this-system-triplet/bin/arm-linux-gnueabi-gcc etc
with kernel support, as already suggested in this thread, one could omit the /x-y-z part, but that is not something to be done "for yesterday".
And then the triplet name problem:
/armv7hl-vendor-linux-gnueabi/lib/ld.so.3 or /arm-linux-gnueabihf/lib/ld.so.3
With this approach, not pretending to share files between sysroots, that can be easily done, but requires strong policy to not allow binaries in /usr/share if /usr/share it to be, err "shared".
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,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
Paulo