[libvirt] gnulib tests in libvirt broken by newer glibc 2.26

[Christian Ehrhardt]

On Thu, Sep 28, 2017 at 12:25 AM, Eric Blake <eblake at redhat.com> wrote:

> [adding gnulib]
>
> On 09/27/2017 04:36 PM, Christian Ehrhardt wrote:
> > Hi,
> > there seems to be an incompatibility to the last glibc due to [1].
>
> Gnulib needs to be updated to track the glibc changes (it looks like
> that is actually under way already),


Yeah that seems to be part of the effort I linked.


> then libvirt needs to pick up the
> updated gnulib.


I copied in current gnulib from git and it didn't resolve yet. But maybe it
is just something that still is work in progress.


> I'll leave the rest of your email intact in case it
> helps gnulib readers, but I'll probably help resolve the issue when I
> get a chance.
>



> I'm assuming you hit this failure on rawhide, as that is the platform
> most likely to be using bleeding-edge glibc with the getopt changes?


It was Ubuntu 17.10 (Artful) which is on 2.26

>
> > Eventually this breaks gnulib unittests (and maybe more).
> > Debugging went from an assert, to bidngin different symbols, to changed
> > function names to different header resolution.
> >
> > Because it expects it to behave "posixly" but arguments are changed
> > differently.
> > FAIL: test-getopt-posix
> > =======================
> >
> > ../../../../gnulib/tests/test-getopt.h:754: assertion 'strcmp (argv[1],
> > "donald") == 0' failed
> >
> > # get and build latest libvirt to get the local gnulib
> > $ wget http://libvirt.org/sources/libvirt-3.7.0.tar.xz
> > $ tar xf libvirt-3.7.0.tar.xz
> > $ cd libvirt
> > $ apt build-dep libvirt
> > $ ./autogen.sh
> > $ make -j4
> >
> >
> > You can run the following simplified test derived from the unit test (it
> is
> > much shorter, so easier to debug e.g. in -E).
> >
> > $ cat << EOF >> test1.c
> > #include <config.h>
> > #include <unistd.h>
> >
> > #include <stdbool.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> >
> > int main (void)
> > {
> >         return 0;
> > }
> > EOF
> > $ gcc -I ./gnulib/lib -I . test1.c -H
> >
> > You can see in -H output already the difference in the paths of the
> headers
> > that it uses:
> >
> > Glibc <2.26
> > . ./config.h
> > .. ./config-post.h
> > . /usr/include/unistd.h
> > [...]
> > .. /usr/include/getopt.h
> >
> > Glibc >=2.26
> > . ./config.h
> > .. ./config-post.h
> > . ./gnulib/lib/unistd.h
> > [...]
> >
> > ... /usr/include/x86_64-linux-gnu/bits/getopt_posix.h
> > .... /usr/include/x86_64-linux-gnu/bits/getopt_core.
> >
> >
> > If you build with -E you'll also see that it now uses getopt from glibc
> > instead of the prefixed rpl_getopt from gnulib.
> >
> > It behaves as if it would not find gnulib and instead fall back to glibc.
> > But it finds gnulib, instead due to glibc's changes its implementation is
> > fetched before and due to that pulling in glibc's behavior while the unit
> > test is verifying against the one it expects from gnulib.
> >
> >
> > Sorry, but I don't see the right fix here yet - I could easily silence
> the
> > test but that is no fix. Especially if there might be implications due to
> > handling the args (slightly) differently.
> >
> > I really wanted to come up with the same test against gnulib alone, but I
> > was lost in the build system for too long and could not get the example
> to
> > fail without libvirt (OTOH I'm sure it would).
> >
> > Therefore I'm reaching out to you for your help and experience on the
> build
> > system what could be done.
> >
> > [1]: https://sourceware.org/ml/libc-alpha/2017-04/msg00115.html
> >
> >
> >
> > --
> > libvir-list mailing list
> > libvir-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
> >
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170928/531b1219/attachment-0001.htm>