On Thu, 2019-02-28 at 15:52 +0000, Daniel P. Berrangé wrote: > On Tue, Feb 26, 2019 at 07:04:16PM +0100, Andrea Bolognani wrote: [...] > > > +++ b/guests/host_vars/libvirt-debian-9/main.yml > > > @@ -21,3 +21,47 @@ os_name: 'Debian' > > > os_version: '9' > > > > > > ansible_python_interpreter: /usr/bin/python3 > > > + > > > +arches: > > > + aarch64: > > > + package_arch: arm64 > > > + abi: aarch64-linux-gnu > > > + cross_gcc: gcc-aarch64-linux-gnu > > > > We previously agreed to store this information in cross-build.yml > > rather than main.yml, and that's what it looked like in v3... Can > > you please move it back there? > > I moved it back here as the pacakge_arch / abi fields are not > specific to cross builds. They're general information about the > distro / toolchain... > > but this all goes away with a static mapping in the code instead > so it doesn't matter. Okay, fair enough. For whatever local override we might need though, eg. to disable cross-building for i386 on Debian 9, we still want to use a separate facts file. > > I also questioned a few respins back whether we need to have the > > Debian 9 configuration at all. For MinGW builds we use Fedora Rawhide > > as the base, so using Debian Sid for cross-builds would make sense, > > especially since it supports more target architectures: we are only > > going to build a single set of buildenv-cross-* container images > > anyway... > > What we do with MinGW right now is not a good example to follow. > There are enough differences betweeen software versions that I > see failures building on stable Fedora that don't appear on > rawhide & vica-versa. This is particularly causing me pain for > virt-viewer release builds as the msi build process is frequently > failing due to changed DLL versions. So when I add MSI builds to > the CI, I'll want MinGW packages across mulitple distro versions. > > The other problem is that both rawhide & sid are rolling unstable > distros which break. Right now I can't even test the cross arch > builds on Sid because some recent update has broken the ability > to install the cross compiler toolchain at all. So only supporting > the unstable Sid is not a good idea. Alright, makes sense. > > > + i686: > > > + package_arch: i386 > > > + abi: i686-linux-gnu > > > + cross_gcc: gcc-i686-linux-gnu > > > > The value of 'abi' doesn't look right: based on eg. > > > > https://packages.debian.org/sid/i386/libglib2.0-dev/filelist > > > > it should be 'i386-linux-gnu' instead. > > The 'abi' is what is prefixed on the toolchain binaries, > and so for this purpose i686-linux-gnu is actually correct: > > https://packages.debian.org/sid/amd64/gcc-i686-linux-gnu/filelist Okay, so I guess you need to have cross_target=i686-linux-gnu for ENV CONFIGURE_OPTS "--host={cross_target} \ --target={cross_target}" to work; however, that will cause issues for ENV PKG_CONFIG_LIBDIR "/usr/lib/{cross_target}/pkgconfig" because as shown above paths look like /usr/lib/i386-linux-gnu/pkgconfig/glib-2.0.pc and so on. What an inconsistent mess! Does it mean we need to carry around both? :( ... Actually, it doesn't look like it: I just tried cross-building for i686 (on sid/x86_64) by simply passing --host=i686-linux-gnu --target=i686-linux-gnu and the build system was able to locate all necessary dependencies despite not having set $PKG_CONFIG_LIBDIR in the environment! This seems to be thanks to i686-linux-gnu-pkg-config, which is a symlink to /usr/share/pkg-config-crosswrapper, being picked up and invoked instead of the native one. tl;dr It looks like we can generate 'cross_gcc' programmatically and we can even get rid of one ENV statement! Neat :) [...] > > One last point is about the possible values: 'skip' and 'native' are > > perfectly intuitive, but I feel like 'foreign' is not that great a > > name, and it also already has a meaning in the context of Debian's > > Multi-Arch implementation which might muddy the waters for people. > > I think 'cross' would be a better value. > > "foreign" is the logical inverse of "native", so I think it is > actually the right word to use here. "cross" is misleading as > we're not installing a cross-built package, we're installing > the native built package from the foreign architecture. Sure, let's keep it that way then. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
