On Tue, Nov 03, 2020 at 06:01:12PM +0100, Philippe Mathieu-Daudé wrote:
> On 11/3/20 5:52 PM, Daniel P. Berrangé wrote:
> > On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote:
> >> We test './configure --without-default-devices' since commit
> >> 20885b5b169 (".travis.yml: test that no-default-device builds
> >> do not regress") in Travis-CI.
> >>
> >> As we prefer to use GitLab-CI, add the equivalent job there.
> >>
> >> One minor difference: the GitLab Ubuntu docker image has the
> >> Xen devel packages installed. As it is automatically selected,
> >> we need to disable it with the --disable-xen option, else the
> >> build fails:
> >>
> >> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function
> >> `xen_be_register_common':
> >> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops'
> >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8):
> >> undefined reference to `local_ops'
> >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20):
> >> undefined reference to `synth_ops'
> >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38):
> >> undefined reference to `proxy_ops'
> >> collect2: error: ld returned 1 exit status
> >
> > Surely this is a build bug we need to fix rather than ignore in CI ?
>
> Well it predates this series, so nobody really cared
> (thus I wonder if it makes sense to invest resources
> there).
>
> Anyway I can have a look after 5.2-rc1.
Can you just put a comment in the .gitlab-ci.yml file stating
that the --disable-xen arg is a short term workaround that needs
to be fixed properly
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
