Comment 18 for bug 1718668

So summarizing, while I fail to see the way to a fix I can now quite well summarize the issue and provide steps to reproduce.
I'll go to the devel mailing list with that:

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 latest libvirt to get their style of local gnulib
# (sorry I couldn't get git://git.sv.gnu.org/gnulib.git to work showing the issue, yet I also couldn't identify a fix there that I could leverage)
$ 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
$ gcc -Wall -I ./gnulib/lib -I . test.c -o test -H

I really wanted to come up with the same against gnulib itself, but I was lost in the build system for too long and hope one can translate it if you think it is needed.
Well until then you can run the following simplified test derived from the unit test (it is much shorter, so easier to debug).

$ 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
[...]
... ./gnulib/lib/getopt.h

If you build with -E you'll also see that it now uses getopt from glibc instead of the prefixed rpl_getopt from gnulib.

Sorry, but I don't see the right fix here - I could easily silence the test but that is no fix. Especially since this might have all sort of implications due to handling the args (slightly) differently. Therefore '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