Daniel P. Berrangé authored Jun 30, 2015 and Cedric Bosdonnat committed Jul 01, 2015

The libc.so library requires certainly functionality to be
provided by the ld-linux.so library. The ld-linux.so is loaded
by the kernel based on the PT_INTERP ELF section, and as such
LD_LIBRARY_PATH has no effect.

So, although libvirt-sandbox-init-{qemu,lxc} set LD_LIBRARY_PATH
to force use of the libs from the host OS image, the common
init program was stil using the ld-linux.so from the guest OS
image. Sometimes this works, sometimes it breaks.

When trying to run Fedora 19 as the root filesystem from a
Fedora 22 host, it would break thus:

/etc/libvirt-sandbox/scratch/.libs/libvirt-sandbox-init-common: relocation error: /etc/libvirt-sandbox/scratch/.libs/libc.so.6: symbol _dl_find_dso_for_object, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

To deal with this we must ensure that we always invoke the
libvirt-sandbox-init-common program using the ld-linux that
was provided by the host OS image.

The sandbox builder is tweaked so that it always copies the
host ld-linux.so into the libs scratch directory, and gives
it a predictable name 'ld.so', since every architecture seems
to have a different name.

The libvirt-sandbox-init-{lxc,qemu} files are changed so that
instead of exec'ing libvirt-sandbox-init-common directly, they
will load it via the ld.so file.