Sorry for the spam. Thunderbird and GMail are not friends today. On Apr 10, 2012 9:46 AM, "Michael Edwards" <[email protected]> wrote:
> 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 > >
_______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
