Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Simon Richter <email@example.com> writes:
>> >, since
>> > they have entirely different objectives
>> Not entirely different - the objective for the packaging tools is
>> actually the same, to have packages install cleanly without changes on
>> systems with a different architecture triplet.
> I'm not sure this can be achieved at all, as we still need a root
> filesystem that isn't prefixed with the architecture triplet.
Why? At least libraries are just fine in the triplet dirs. As said
binaries should not move. For cross-building dpkg-cross can move them
during unpacking if that is needed.
> The other issue is that generally, the 32/64 bit distinction does not
> necessarily mean that we use a different triplet. i386/amd64 does, at least
> in Debian, but that is optional as well and could be changed in the gcc
> package, which would give us a situation where only clearly incompatible
> arches need to be installed into a triplet directory.
Then change the triplets. Having binary files for multiple
architectures in the same triplet dirs works neither for multiarch nor
>> >, and there is generally no need to
>> > install anything but libraries and headers into /usr/<triplet> -- so I
>> > don't think there is a pressing need to replicate a filesystem hierarchy
>> > standard below a triplet directory.
>> True, however, that is not a sufficient reason to not
>> move /usr/<triplet> to /usr/lib/<triplet> and /usr/include/<triplet>
>> if it means getting such support into the core Debian packaging tools.
> Indeed, however this makes building stuff without the packaging tools a lot
> harder -- for example I need to patch gcc to recognize these paths if I
> build gcc by hand. It might be a lot easier to have the packaging tools
> handle the "current" layout than to patch all the software that assumes
> that software is generally installed into "include" and "lib" dirs under a
> common prefix (such as most GNU software that uses the autoconf macros to
> find installed software).
The current layout does not result in a bootable system. We do need
and then stuff already needs patching.
Also current setup is:
% ldconfig -v | grep :
/usr/lib32/i586: (hwcap: 0x0004000000000000)
/usr/lib32/i486: (hwcap: 0x0002000000000000)
/usr/lib32/i686: (hwcap: 0x0008000000000000)
/usr/lib32/i686/cmov: (hwcap: 0x0008000000008000)
ldconfig has no idea about cross-compile dirs. And someone suggested
they should be system dirs hardcoded into the binary and not via