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! -- Loïc Minier _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain