Hi, last week I tried exploiting multiarch to set up a machine to build and run binaries for multiple architectures.
So I enabled architectures in dpkg, updated the package lists and tried
installing libc6 packages for each architecture, but dpkg refused to unpack
libc6:mipsel after libc6:powerpc had been installed, because both
architectures use the same path for their dynamic loader: /lib/ld.so.1
A look into the archive revealed two groups of conflicting loader paths:
/lib/ld.so.1:
hppa hurd-i386 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe s390
/lib/ld-linux.so.2:
alpha i386 sh4 sparc
Other architectures have loader paths containing the architecture name (amd64
arm64 armhf kfreebsd-amd64 x32) or ones that are merely unique: /lib/ld-
linux.so.3 (armel), /lib/ld64.so.1 (s390x), /lib64/ld64.so.1 (ppc64),
/lib64/ld64.so.2 (ppc64el), /lib64/ld-linux.so.2 (sparc64).
The problem is that loader paths are hard to change, at least for binaries
that need to be run at boot time. Later we can use binfmt-support to call the
loader with its multiarch'ed path or change qemu-user in that way.
A short-term fix for the dpkg errors could be to express the conflicting
loader paths with Conflicts: between the relevant libc6 packages.
My proposal for a long-term solution is:
* qemu-user redirects loader names to multiarch'ed paths
* libc6 adds binfmt entries for the native architectures
* libc6 removes the loader symlinks from the package tarball and instead
creates it in maintainer scripts for the native architecture(s)
Is that a workable plan or did I miss something?
Greetings
Timo
signature.asc
Description: This is a digitally signed message part.
