Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
> >, 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.
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.
> >, 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).