Re: [Qemu-devel] [PATCH v6 2/8] tests/docker/docker.py: support --include-executable

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrange <berrange@redhat.com> writes:

> On Tue, Jul 19, 2016 at 04:16:42PM +0800, Fam Zheng wrote:
>> From: Alex Bennée <alex.bennee@linaro.org>
>>
>> When passed the path to a binary we copy it and any linked libraries (if
>> it is dynamically linked) into the docker build context. These can then
>> be included by a dockerfile with the line:
>>
>>   # Copy all of context into container
>>   ADD . /
>>
>> This is mainly intended for setting up foreign architecture docker
>> images which use qemu-$arch to do cross-architecture linux-user
>> execution. It also relies on the host and guest file-system following
>> reasonable multi-arch layouts so the copied libraries don't clash with
>> the guest ones.
>
> So that's going to fail on anything other than Debian derivatives,
> since they'll be using /usr/lib or /usr/lib64 for all arches.

Well currently we only have a bootstrap for Debian anyway. However it
doesn't preclude you from using -static builds if you want.

Is Debian really the only multi-arch supporting distro out there? For
example I tested this in Arch as well. I'm fairly sure Gentoo is doing
it right too.

> IMHO it'd be better to simply reject use of qemu-$arch if it is
> not statically linked, rather than trying to deal with fact that
> libraries between host FS and foreign guest arch FS may clash.
>
> All distros except Fedora have long provided static qemu-$arch
> builds and I've recently improved Fedora to also provide static
> qemu$arch builds in F24 & rawhide.

That's great but we also want to test our built qemus. For example the
hot-path stuff has all been tested inside docker containers because it
makes the setting up of test cases a lot simpler and reproducible.

>
> So I don't see much compelling reason to support dynamically
> linked qemu-$arch binaries - it'll just cause pain & suffering
> with clashing libs on many distros.

I do, because I built with dynamic libs all the time for system
emulation. This way it is simple to build test other arches when I'm
making system emulation changes without having to constantly switch from
one build configuration to another.

I'll look into if there is any way we can do better with warnings on
non-multiarch systems?

--
Alex Bennée