On Mon, Sep 12, 2016 at 05:15:53PM +0200, Michal Privoznik wrote: > On 12.09.2016 16:54, Daniel P. Berrange wrote: > > On Tue, Sep 06, 2016 at 03:46:59PM +0200, Michal Privoznik wrote: > >> In the latest glibc, major() and minor() functions are marked as > >> deprecated (glibc commit dbab6577): > >> > >> CC util/libvirt_util_la-vircgroup.lo > >> util/vircgroup.c: In function 'virCgroupGetBlockDevString': > >> util/vircgroup.c:768:5: error: '__major_from_sys_types' is deprecated: > >> In the GNU C Library, `major' is defined by <sys/sysmacros.h>. > >> For historical compatibility, it is currently defined by > >> <sys/types.h> as well, but we plan to remove this soon. > >> To use `major', include <sys/sysmacros.h> directly. > >> If you did not intend to use a system-defined macro `major', > >> you should #undef it after including <sys/types.h>. > >> [-Werror=deprecated-declarations] > >> if (virAsprintf(&ret, "%d:%d ", major(sb.st_rdev), minor(sb.st_rdev)) < 0) > >> ^~ > >> In file included from /usr/include/features.h:397:0, > >> from /usr/include/bits/libc-header-start.h:33, > >> from /usr/include/stdio.h:28, > >> from ../gnulib/lib/stdio.h:43, > >> from util/vircgroup.c:26: > >> /usr/include/sys/sysmacros.h:87:1: note: declared here > >> __SYSMACROS_DEFINE_MAJOR (__SYSMACROS_FST_IMPL_TEMPL) > >> ^ > >> > >> Moreover, in the glibc commit, there's suggestion to keep > >> ordering of including of header files as implemented here. > >> > >> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > >> --- > >> > >> This still won't solve the build issue completely as AC_HEADER_MAJOR still > >> reports that major() is defined by sys/types.h instead of sys/sysmacros.h. > > > > AFAICT, it doesn't appear to have even fixed the vircgroups.c file > > compile failure - our CI is still broken with the exact same error > > message you have above > > Yes, that's because autoconf macro checking where does major() come from > hasn't been fixed yet. As soon as it is fixed the problem will go away. > Eric, any update on this? Oh I misunderstood then - i thought your meant the configure problem would merely cause a warning message to appear in configure output, not that it would still cause us to have a broken build. We've have rawhide builds of libvirt broken in CI for weeks now. I think we need to fix out configure.ac script in libvirt to deal with this now. As & when autoconf/gnulib get a workaround we can revert our local fix. The priority has to be getting out CI passing again asap. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list