Re: [libvirt] [PATCH] maint: update to latest gnulib

On Sat, 2018-07-14 at 09:20 +0200, Michal Privoznik wrote: 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