Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
>>> , 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).
That's totally right and that is my point, I really think multiarch is
not well designed to fit into cross compiling. They (dpkg-core) might
want us to do extra work which will break our stuff.
And as from the point of view of multiarch we probably have a nice,
simple and working solution right now, without even notice it. The only
reason I found against our approach is:
Why not prefix/arch-os/lib/ (and include/)?
It would pollute the prefix directory. Can you imagine adding one entry
for each target to the root and /usr directories? Better that they go
under the prefix/lib/ (and include/) directories which already contain
many files. "
Which in practice it is not so bad to do all the extra work that
multiarch needs to get done.
Please correct me if I am wrong