On 01/10/2017 01:36 AM, Florian Weimer wrote:
On 01/09/2017 03:37 PM, Dennis Gilmore wrote:
the only reason that aarch64 used /usr/lib64 was so it looked more like
x86_64 from a user perspective, there is 64 bit arches like alpha that
use /usr/lib for their libraries.
We'll see soon what the non-multiarch layout will be for aarch64 (but
hopefully not in Fedora). Maybe something like this?
/usr/lib ARMv7/armhfp binaries
/usr/lib64 aarch64 64-bit binaries
/usr/lib32 aarch64 in ILP32 mode (32-bit binaries)
This is similar to x86_64, where the conjectured layout is:
/usr/lib i386
/usr/lib64 x86_64 64-bit binaries
/usr/libx32 x86_64 in ILP32 (x32, 32-bit binaries)
These seem so arbitrary though- that's the appeal of a gnu triplet,
even though Debian doesn't take full advantage of it.
The Debian multi-arch approach has the advantage that it provides a
consistent way to determine the paths, and also a systematic way to
deal with file conflicts in /usr/include.
Making the compiler sys-root and the runtime the same path and
binaries is really nice. Pursuing this path would also mean changing
dnf/rpm since today they generally don't like to install packages for
non-native architectures.
Stephen, are we in a seductive detail here or is this conversation
applicable to your original problem?
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
