Multiarch paths and toolchain implications

Ulrich Weigand Ulrich.Weigand at
Mon Aug 2 13:00:06 BST 2010

Loïc Minier <loic.minier at> wrote:

>  Awesome analysis!


>  So I think you analyzed the upstream toolchain behavior

Yes, that's true.

>  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.

Agreed.  Not sure what this particular divergence helps ...

> >   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),

This seems awkward.  The ELF interpreter location is encoded as full path,
which is not interpreted in any way by the kernel.  We'd either have to
encode particular filesystem layout knowledge into the kernel here, or
else add a prefix at the very beginning (or end?), which doesn't correspond
to the scheme suggested for multiarch.

If we go down that route, it might be easier to use tricks like bind-
mounting the correct for this architecture at the default location
during early startup or something ...

However, I'd have thought the whole point of the multiarch scheme was to
*avoid* having to play filename remapping tricks, but instead make all
filenames explicit.

>  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.

Well, but then what architecture would that generic loader be in?  In the
end, it has to be *something* the kernel understands to load natively.

>  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).

But binfmt_misc only works because in the end it falls back to the built-
in native ELF loader.  (You can install arbitrary handlers, but the
handlers themselves must in the end be something the kernel already
knows how to load.)

> >   Option C: 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.

That's one of the fundamental design questions: do we want to make sure
only multiarch libraries for the correct arch can ever be found, or do we
rather want to make sure on a default install, libraries that have not yet
been converted to multiarch can also be found (even taking the chance that
they might turn out be of the wrong architecture / variant) ...

>  BTW, the CodeSourcery patchset contains a "directory poisoning" feature
>  which seems quite useful to detect these cases early.

Yes, that's during compile time.  I understand the reason for this is more
to catch bad include paths manually specified in packages.  Not sure if
during load time the same concerns apply.

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294

More information about the linaro-toolchain mailing list