Em 11 de abril de 2012 10:04, Steve McIntyre <steve.mcint...@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.mcint...@linaro.org > <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs > > > _______________________________________________ > cross-distro mailing list > cross-dis...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/cross-distro Paulo _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
