[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain



Simon Richter <sjr@debian.org> writes:

> Hi,
>
>> >, 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
cross-building.

>> >, 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).
>
>    Simon

The current layout does not result in a bootable system. We do need

/arch-os-libc/lib/

and then stuff already needs patching.

Also current setup is:
% ldconfig -v | grep :
/usr/lib/i486-linux-gnu:
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/lib:
/lib32:
/usr/lib:
/usr/lib32:
/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
conffiles.

MfG
        Goswin


Reply to: