On Tue, Jul 19, 2016 at 04:16:42PM +0800, Fam Zheng wrote: > From: Alex Bennée <alex.ben...@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. 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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|