Hi,
I'm trying to put together a summary of what distributions have hopped on the Multiarch /lib/<triplet> bandwagon (or plan to), and for those who haven't, what their solution is to dealing with various instruction sets, system call interfaces, application binary interfaces, etc. on a single root filesystem.
Here's what I've gathered so far. Links to up-to-date documentation on the subject, and any corrections or additions to my little list would be greatly appreciated.
Ubuntu, Debian Multiarch: /lib/<triplet>
Fedora, OpenSUSE Multilib A: /lib, /lib64
Arch Multilib B: /lib32, /lib
Gentoo Multilib C: /lib32, /lib64, /libx32
OpenEmbedded Uniarch A: /lib
Android: Uniarch B: /system/lib
Also, any news on related LSB/FHS or other standardization efforts?
Thanks, Christopher
On Monday 22 April 2013 14:42:44 Christopher Covington wrote:
I'm trying to put together a summary of what distributions have hopped on the Multiarch /lib/<triplet> bandwagon (or plan to), and for those who haven't, what their solution is to dealing with various instruction sets, system call interfaces, application binary interfaces, etc. on a single root filesystem.
Gentoo plans on following standard multilib behavior (what gcc/glibc use)
based on the paths before, it looks like you're really only sampling the x86 architecture ?
Gentoo Multilib C: /lib32, /lib64, /libx32
/lib32 is the historical 32bit x86 path. we're migrating away from that and to /lib. Gentoo uses the standard paths for all other ABIs. -mike
Hi Mike,
On 04/22/2013 03:11 PM, Mike Frysinger wrote:
On Monday 22 April 2013 14:42:44 Christopher Covington wrote:
I'm trying to put together a summary of what distributions have hopped on the Multiarch /lib/<triplet> bandwagon (or plan to), and for those who haven't, what their solution is to dealing with various instruction sets, system call interfaces, application binary interfaces, etc. on a single root filesystem.
Gentoo plans on following standard multilib behavior (what gcc/glibc use)
based on the paths before, it looks like you're really only sampling the x86 architecture ?
I'm mostly interested in ARM and x86, but curious about other architectures too, if they're handled differently. My thinking as that those who have 32-bit ARM support but don't yet have aarch64/arm64 support might adopt the same style their x86 support is already using, should they find ARM's 64-bit ISA sufficiently interesting.
Gentoo Multilib C: /lib32, /lib64, /libx32
/lib32 is the historical 32bit x86 path. we're migrating away from that and to /lib. Gentoo uses the standard paths for all other ABIs.
Thanks, Christopher
On Monday 22 April 2013 16:28:49 Christopher Covington wrote:
On 04/22/2013 03:11 PM, Mike Frysinger wrote:
On Monday 22 April 2013 14:42:44 Christopher Covington wrote:
I'm trying to put together a summary of what distributions have hopped on the Multiarch /lib/<triplet> bandwagon (or plan to), and for those who haven't, what their solution is to dealing with various instruction sets, system call interfaces, application binary interfaces, etc. on a single root filesystem.
Gentoo plans on following standard multilib behavior (what gcc/glibc use)
based on the paths before, it looks like you're really only sampling the x86 architecture ?
I'm mostly interested in ARM and x86, but curious about other architectures too, if they're handled differently. My thinking as that those who have 32-bit ARM support but don't yet have aarch64/arm64 support might adopt the same style their x86 support is already using, should they find ARM's 64-bit ISA sufficiently interesting.
for Gentoo, we are not going to do reshuffling for aarch64. /lib holds the ARM 32bit libs and /lib64 will hold the aarch64 libs. it'll be this way regardless of host kernel and default ABI. -mike
Brought this up for discussion with our devs. We haven't yet really gotten that far into ARMv8. I'm not sure that there are too many proprietary pieces of software that require 32 bit on ARM at the moment. We'll probably start with a pure 64 bit environment at the beginning and reevaluate later on when the random software pops up.
Mike Brown Arch Linux ARM
On Mon, Apr 22, 2013 at 5:15 PM, Mike Frysinger vapier@gentoo.org wrote:
On Monday 22 April 2013 16:28:49 Christopher Covington wrote:
On 04/22/2013 03:11 PM, Mike Frysinger wrote:
On Monday 22 April 2013 14:42:44 Christopher Covington wrote:
I'm trying to put together a summary of what distributions have hopped on the Multiarch /lib/<triplet> bandwagon (or plan to), and for those who haven't, what their solution is to dealing with various
instruction
sets, system call interfaces, application binary interfaces, etc. on a single root filesystem.
Gentoo plans on following standard multilib behavior (what gcc/glibc
use)
based on the paths before, it looks like you're really only sampling
the
x86 architecture ?
I'm mostly interested in ARM and x86, but curious about other
architectures
too, if they're handled differently. My thinking as that those who have 32-bit ARM support but don't yet have aarch64/arm64 support might adopt the same style their x86 support is already using, should they find ARM's 64-bit ISA sufficiently interesting.
for Gentoo, we are not going to do reshuffling for aarch64. /lib holds the ARM 32bit libs and /lib64 will hold the aarch64 libs. it'll be this way regardless of host kernel and default ABI. -mike
W dniu 22.04.2013 20:42, Christopher Covington pisze:
Fedora, OpenSUSE Multilib A: /lib, /lib64
Arch Multilib B: /lib32, /lib
Gentoo Multilib C: /lib32, /lib64, /libx32
OpenEmbedded Uniarch A: /lib
There is a work on multilib in OE. Probably "A" version as it is upstream one.
Hi Christopher,
You are correct about Fedora. Fedora will likely never go "multi-arch" (although I personally find it interesting, it is seen as exotic and disfavored by most folks I speak with in the Fedora community). We have ensured AArch64 library paths are unified with other RPM distros. On LSB, I spoke with folks about LSB in SF last week. Will followup on AArch64 LSB.
Sent from a plane. Buffered until landing.
Jon.
-
Christopher Covington -
Jon Masters -
Marcin Juszkiewicz -
Mike Brown -
Mike Frysinger