Awesome analysis!
On Sat, Jul 31, 2010, Ulrich Weigand wrote:
$(version) GCC version number
So I think you analyzed the upstream toolchain behavior, and I think Debian/Ubuntu toolchains cheat in some areas; for some directories which would use $(version) we use $(major).$(minor) instead, and we have a $(version) -> $(major).$(minor) symlink. This doesn't really relate to the multiarch topic, but it reminds me that we ought to fix the distro divergences so that it's easier to swap an upstream toolchain with a Debian/Ubuntu one and vice-versa.
I don't remember where this particular setup comes from; it might to avoid overly strict or painful dependencies.
Executables built with the old ELF interpreter will not run on a system that *only* provides the multiarch install location. This is clearly *not* OK. To provide backwards compatibility, even a multiarch-capable system will need to install ELF interpreters at the old locations as well, possibly via symlinks. (Note that any given system can only be compatible in this way with *one* architecture, except for lucky circumstances.)
I see two ways around this; we could patch the kernel to add a dynamic prefix before the runtime-linker path depending on the executable contents (typically depending on the arch), or more elegantly we could have a generic loader which checks the architecture of the target ELF file before calling the arch-specific loader. This loader would be linked to from all the old locations.
The reason I'm thinking of patching the kernel is because binfmt_misc is already out there and allows special behavior when encountering binary files from other architectures (or any binary pattern really).
Option C: ld.so searches both the -rpath as is, and also with multiarch target string appended.
This is a risk for cross-builds; the native version might be picked up. While this doesn't seem much of a risk for cross-compilation to an entirely different architecture (e.g. x86 to ARM), consider cross-builds from x86-64 to x86, or from EABI + hard-float to EABI + soft-float.
BTW, the CodeSourcery patchset contains a "directory poisoning" feature which seems quite useful to detect these cases early.
Thanks again for your writeup!