On 06/29/2016 12:34 PM, Daniel P. Berrange wrote:
On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
>> Debian handles this by having several packages 
>> - qemu-user - the dynamic linked qemu user binaries
>> - qemu-binfmt - binfmt rules registering the dynamic linked binaries
>> - qemu-user-static - the static linked qemu user binaries *and* binfmt
>> rules to register them. The static binaries all
>> have -static suffix on their name
> Debian builds static libraries and puts them into their -dev packages.
> Fedora does not do this systematically. Are all the static libraries you
> need actually available in Fedora?
Yes, everything we need exists - as mentioned its only glibc-static,
glib2-static, zlib-static and pcre-static that we need for this.
In this case, linking statically is indeed an option.
We currently have little tooling for static libraries. Strictly
speaking, all statically linked libraries have to be rebuilt even for
minor glibc updates because we do not provide ABI compatibility for
static linking (there are no compatibility symbols, static binaries
always get the most recent implementation).
> An alternative would be to bind-mount the real file system into
> and run the native dynamic linker with a --library-path command line
> argument that specifies the library directories in the bind mount. (It's
> reasonable to specify --inhibit-cache as well.) This would need some
> adjustments in the binfmt wrapper.
The binfmt registrations are global to the OS, so the same binfmt command
needs to work whether inside or outside the chroot. So a scheme which
requires us to pass special args to make the linker looks elsewhere when
inside the chroot is not so easy. We'd have to create a wrapper program
around the real qemu user binary that decides which args to pass to the
linker, and that wrapper would then have to be statically linked
Yes, but it would be much simpler than the whole QEMU binary with its