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
Attachment:
signature.asc
Description: This is a digitally signed message part.