On Mon, 2019-01-28 at 12:03 +0000, Daniel P. Berrangé wrote: [...] > cross-build/arch-config.csv | 8 +++ > cross-build/buildenv-cross.docker.in | 96 ++++++++++++++++++++++++++++ > 3 files changed, 105 insertions(+) > create mode 100644 cross-build/arch-config.csv > create mode 100644 cross-build/buildenv-cross.docker.in You're providing a Dockerfile template and a CSV file containing the data that should be substituted into it, and it's fairly obvious how one would go about it, but I would expect you to provide a script and possibly a Makefile along with this... I assume you just forgot to commit them? :) [...] > +++ b/cross-build/arch-config.csv > @@ -0,0 +1,8 @@ > +arm64,crossbuild-essential-arm64,aarch64-linux-gnu > +armel,crossbuild-essential-armel,arm-linux-gnueabi > +armhf,crossbuild-essential-armhf,arm-linux-gnueabihf > +mips64el,gcc-mips64el-linux-gnuabi64,mips64el-linux-gnuabi64 > +mips,gcc-mips-linux-gnu,mips-linux-gnu > +mipsel,gcc-mipsel-linux-gnu,mipsel-linux-gnu > +ppc64el,crossbuild-essential-ppc64el,powerpc64le-linux-gnu > +s390x,gcc-multilib-s390x-linux-gnu,s390x-linux-gnu The file format is not documented, and it really should be. As for the architecture selection, we should drop armel (it's unlikely to be part of the next Debian release[1]) and possibly all the MIPS architectures too? I'm fairly sure nobody is actually running and testing libvirt on those architectures, so making them official targets for cross-compilation would be a bit dishonest in my opinion. Same possibly goes for armhf, but it's less clear-cut given how many Raspberry Pis are out there. We should also use the virArch names instead of the Debian names, even if that means having additional logic to map between them. [...] > +++ b/cross-build/buildenv-cross.docker.in > @@ -0,0 +1,96 @@ > +# > +# ::ARCH:: cross-compiler target > +# > +FROM debian:stretch-slim How much smaller is the -slim variant than the regular stretch image? Because according to the documentation These tags are an experiment in providing a slimmer base (removing some extra files that are normally not necessary within containers, such as man pages and documentation), and are definitely subject to change. so unless the savings are very significant, I'd much rather stick with the regular images. [...] > +# First some common native binaries. Any program that the > +# build will execute needs to have a native binary package > +# installed. We don't want to rely on qemu-user emulation > +# for executing non-native binaries as that is slow & flaky > +RUN DEBIAN_FRONTEND=noninteractive \ > + apt-get install -y --no-install-recommends \ I never considered it until now, but we might want to use DEBIAN_FRONTEND=noninteractive and --no-install-recommends in our existing Debian/Ubuntu Dockerfiles as well :) [...] > + qemu-system-x86 \ Based on what you wrote just a few lines above, QEMU shouldn't be necessary, so why are you dragging it in? [...] > +# Finally pull in the foreign architecture library > +# packages that we're going to link against. Everything > +# here should be a -dev package. Binaries belong earlier > +RUN DEBIAN_FRONTEND=noninteractive \ > + apt-get install -y --no-install-recommends \ > + libxml2-dev:::ARCH:: \ Given that the format is package:architecture, I'd say ::VAR:: is a pretty poor choice when it comes to marking stuff for substitution... I suggest using good old @VAR@ instead, so the above would look like libxml2-dev:@ARCH@ which is much clearer. [...] > + xfslibs-dev:::ARCH:: \ > + libssh-dev:::ARCH:: \ > + libgnutls28-dev:::ARCH:: How did you come up with this list of packages, anyway? It doesn't match the one in buildenv-debian-9.Dockerfile from the libvirt-dockerfiles repository. On a more general note, we shouldn't have such a list at all: the source of truth for build dependencies are the YAML files in guests/vars/, and anything that needs it should obtain it from there. Which leads me to an even more general point: this should be part of lcitool instead of its own thing. We already have (admittedly not great) code to generate Dockerfiles in there; cleaning it up and extending it so that it can support this additional variant of the same idea shouldn't be too difficult. > +# Tell libvirt which architecture we want to target > +ENV LIBVIRT_CONFIGURE_OPTS "--host=::ABI:: --build=x86_64-linux-gnu --target=::ABI::" > + > +# Tell pkg-config where to find the non-native .pc files > +ENV PKG_CONFIG_LIBDIR=/usr/lib/::ABI::/pkgconfig I really don't like injecting this much environment into the container. Can we limit it to a single $ABI variable, or perhaps even store it on disk as, I don't know, /root/abi or something? Either way, we could pick up the information and prepare the above environment as part of the build process, eg. on the libvirt side. [1] https://release.debian.org/buster/arch_qualify.html -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
