On Sat, 2018-07-14 at 09:20 +0200, Michal Privoznik wrote:
> The changelog is quite long because we haven't updated gnulib in
> a while. Anyway, among the new changes you'll find GCC 8 support,
> faster build time, mingw fixes and many others.
Ironically, this makes building on MinGW *worse* :)
Looking at the CentOS CI, you can see that before[1] updating
gnulib the build failed with
In function 'virStrncpy',
inlined from 'virStrcpy' at ../../src/util/virstring.c:811:12:
../../src/util/virstring.c:789:11: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
ret = strncpy(dest, src, n);
^~~~~~~~~~~~~~~~~~~~~
../../src/util/virstring.c: In function 'virStrcpy':
../../src/util/virstring.c:811:12: note: length computed here
return virStrncpy(dest, src, strlen(src), destbytes);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and after[2] it fails with
../../src/util/virrandom.c: In function 'virRandomInt':
../../src/util/virrandom.c:102:30: error: implicit declaration of function 'ffs' [-Werror=implicit-function-declaration]
return virRandomBits(ffs(max) - 1);
^~~
If you tweak the code to get rid of the ffs() call, you'll see
that the strncpy() error is not resolved - it's merely being swept
under the rug by the new one.
It looks like gnulib commit 2afc250c6fae changed the ffs()
detection code, and now when compiling with MinGW I get HAVE_FFS=1
instead of HAVE_FFS=0 and the failure above. Curiously, HAVE_FFS
only shows up in Makefiles after the commit, whereas before I had
the classic '#undef HAVE_FFS' in config.h as well.
CC'ing bug-gnulib and the patch author so they can take a look.
As for the strncpy() issue, it looks like the latest MinGW in
Rawhide introduced more strict diagnostics that are being mistakenly
triggered in this scenario. I'm looking into it.
[1] https://ci.centos.org/view/libvirt/job/libvirt-master-build-mingw32/238/
[2] https://ci.centos.org/view/libvirt/job/libvirt-master-build-mingw32/239/
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
