[libvirt] [jenkins-ci PATCH v5 5/5] lcitool: support generating cross compiler dockerfiles

[Andrea Bolognani]

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