FWIW, my use case for multiarch is not "sharing the root filesystem among multiple systems". It's "sharing the non-lib namespace (/etc, /bin, data) among multiple instruction sets / ABI variants on the same system". I don't need (/usr)?/s?bin to be decorated with a triplet, because the kernel picks a fresh ld.so variant at the execve() boundary; I am happy to mix ARM and x86 binaries (and Python and shell scripts) in /bin, and let the kernel (and binfmt_misc + qemu) sort it out. I only need (/usr)?/lib to be disambiguated *at runtime* because ld.so is not as smart as the kernel. (It's not just ld.so, of course; module/plugin loaders for everything from Python to Firefox have the same problem, and if they don't have the triplet in there somewhere then multiarch breaks them.)

As long as the kernel can find the right ld.so and each ld.so can find its own ld.so.conf, I don't really care where the libraries are put at runtime, as long as I can make it different for each ISA/ABI. However, I do care how much autoconf / pkg-config / debhelper misery I have to go through each time I need to pull in another library dependency. Upstream build machinery can usually accommodate /just/about/anything/lib. Trailing components like lib32, libhf, or lib-gnu-autoconf-triplet are not as consistently trivial.


Personally, I would like for all shared objects to live in (/usr)?/gnu-autoconf-triplet(-extranoise)?/lib, and for the kernel to take responsibility for pointing (/usr)?/lib at an overlay mount containing whatever makes sense for the currently running binary, a la /proc/self. That way I can grandfather in binaries with ABI-ignorant hard-coded library paths, and still handle ISA variants. The "extranoise" might be "neon", or "ssse3", or "android" (so that non-Android binaries on the same system don't see Android-specific libraries with stupidly generic names like libui.so). And the overlay mount is so that I can, if I choose, build the vast majority of my system without NEON instructions (and thus not take the overhead of VFP context save/restore during timeslices that don't use actual floating point) and still use a subset of those libraries from NEON-anointed binaries (assuming I define some sensible way for the kernel to make that distinction).

That isn't necessarily the right solution, of course -- either at a technical level or in the light of the LSB process and other inter-distro politics. But maybe it's at least a more plausible use case for 2012 than NFS-mounting /usr/local on a mix of sun4c, sun4u, and IRIX workstations. (That never did work quite right ...)

Cheers,
- Michael

Reply via email to