Simon Richter <s...@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
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
