From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPSrV-0000MV-5r for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:06:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPSrQ-0002PN-S9 for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:06:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPSrQ-0002PC-MA for qemu-devel@nongnu.org; Tue, 19 Jul 2016 07:06:48 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 361B463E28 for ; Tue, 19 Jul 2016 11:06:48 +0000 (UTC) Date: Tue, 19 Jul 2016 12:06:45 +0100 From: "Daniel P. Berrange" Message-ID: <20160719110645.GF21295@redhat.com> Reply-To: "Daniel P. Berrange" References: <1468916208-18668-1-git-send-email-famz@redhat.com> <1468916208-18668-3-git-send-email-famz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1468916208-18668-3-git-send-email-famz@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 2/8] tests/docker/docker.py: support --include-executable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org On Tue, Jul 19, 2016 at 04:16:42PM +0800, Fam Zheng wrote: > From: Alex Benn=C3=A9e >=20 > When passed the path to a binary we copy it and any linked libraries (i= f > it is dynamically linked) into the docker build context. These can then > be included by a dockerfile with the line: >=20 > # Copy all of context into container > ADD . / >=20 > 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. 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. 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. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|