Re: [libvirt] [jenkins-ci PATCH v5 5/5] lcitool: support generating cross compiler dockerfiles
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