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

Christian Ehrhardt christian.ehrhardt at canonical.com
Wed Sep 27 22:07:50 UTC 2017


I did an in-place replacement of gnulib to the latest from gnulib upstream
but the issue stays.
So for the time being i'd assume it is not yet solved there.

On Wed, Sep 27, 2017 at 11:36 PM, Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

> Hi,
> there seems to be an incompatibility to the last glibc due to [1].
>
> 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
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>



-- 
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/5a8a6739/attachment-0001.htm>


More information about the libvir-list mailing list