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

Reply via email to