[PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Edwards]

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