Fedora rawhide has just upgraded to the latest glibc git master snapshot, of what will become the 2.28 release, and this has exposed bugs in gnulib's fseeko.c implementation (and probably more macros) besides. The issue starts are line 50: http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/fseeko.c#n50 #if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */ Historically the _IO_ftrylockfile symbol has been defined unconditionally in glibc, by /usr/include/libio.h, which is pulled in unconditionally from /usr/include/stdio.h The libio.h header was deprecated in 2.27 release and is removed in git master for future 2.28. Thus the _IO_ftrylockfile symbol has gone away. https://sourceware.org/ml/libc-announce/2018/msg00000.html "The nonstandard header files <libio.h> and <_G_config.h> are deprecated and will be removed in a future release. Software that is still using either header should be updated to use standard <stdio.h> interfaces instead. libio.h was originally the header for a set of supported GNU extensions, but they have not been maintained as such in many years, they are now standing in the way of improvements to stdio, and we don't think there are any remaining external users. _G_config.h was never intended for public use, but predates the bits convention." We then fail the __GNU_LIBRARY__ test too, because modern glibc defines that to a value of '6', not '1'. For added fun __GNU_LIBRARY__ is considered deprecated too, with recommendation to use other symbols like __GLIBC__ and __GLIBC_MINOR__ /* This macro indicates that the installed library is the GNU C Library. For historic reasons the value now is 6 and this will stay from now on. The use of this variable is deprecated. Use __GLIBC__ and __GLIBC_MINOR__ now (see below) when you want to test for a specific GNU C library version and use the values in <gnu/lib-names.h> to get the sonames of the shared libraries. * #define __GNU_LIBRARY__ 6 I hit failure on fseeko.c, but many other files in gnulib test on _IO_ftrylockfile so I presume they are all broken. I'm curious why we're trying to replace fseeko impl at all, since I would expect the modern glibc impl to be suitable to use as-is. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
