Eric Blake
2017-09-27 22:25:24 UTC
[adding gnulib]
that is actually under way already), then libvirt needs to pick up the
updated gnulib. 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?
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 likethere seems to be an incompatibility to the last glibc due to [1].
that is actually under way already), then libvirt needs to pick up the
updated gnulib. 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?
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
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
https://www.redhat.com/mailman/listinfo/libvir-list
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
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
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
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org