[libvirt] build failure on 32-bit
I hit an interesting failure on my 32-bit F24 machine: In file included from ../../src/util/virconf.c:32:0: ../../src/util/virconf.c: In function 'virConfGetValueSSizeT': ../../src/util/virconf.c:1269:26: error: format '%zd' expects argument of type 'signed size_t', but argument 9 has type 'long int' [-Werror=format=] _("%s: value for '%s' parameter must be in range %zd:%zd"), In context, it is because we are using SSIZE_MAX as the argument paired to %zd. Technically, the standards documents do NOT require ssize_t to have any relation to size_t, and thus there is NO portable way to pass ssize_t values to printf() without a cast; but in practice, most systems are sane enough that 'ssize_t' is the same type as 'signed size_t', as requested by gcc. This includes 32-bit glibc (where size_t is unsigned int, and ssize_t is int). But it turns out it is a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13575 - SSIZE_MAX must have type ssize_t, and glibc is at fault for defining it as a 'long' value even when ssize_t is an 'int'. Once gnulib works around it, I'll update libvirt's gnulib submodule to fix the libvirt build on 32-bit Linux again. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Jul 12, 2016 at 11:48:11AM -0600, Eric Blake wrote:
I hit an interesting failure on my 32-bit F24 machine:
In file included from ../../src/util/virconf.c:32:0: ../../src/util/virconf.c: In function 'virConfGetValueSSizeT': ../../src/util/virconf.c:1269:26: error: format '%zd' expects argument of type 'signed size_t', but argument 9 has type 'long int' [-Werror=format=] _("%s: value for '%s' parameter must be in range %zd:%zd"),
In context, it is because we are using SSIZE_MAX as the argument paired to %zd.
Technically, the standards documents do NOT require ssize_t to have any relation to size_t, and thus there is NO portable way to pass ssize_t values to printf() without a cast; but in practice, most systems are sane enough that 'ssize_t' is the same type as 'signed size_t', as requested by gcc. This includes 32-bit glibc (where size_t is unsigned int, and ssize_t is int).
But it turns out it is a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13575 - SSIZE_MAX must have type ssize_t, and glibc is at fault for defining it as a 'long' value even when ssize_t is an 'int'.
Once gnulib works around it, I'll update libvirt's gnulib submodule to fix the libvirt build on 32-bit Linux again.
Should we just add a cast temporarily ? 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 :|
On 07/13/2016 03:14 AM, Daniel P. Berrange wrote:
On Tue, Jul 12, 2016 at 11:48:11AM -0600, Eric Blake wrote:
I hit an interesting failure on my 32-bit F24 machine:
In file included from ../../src/util/virconf.c:32:0: ../../src/util/virconf.c: In function 'virConfGetValueSSizeT': ../../src/util/virconf.c:1269:26: error: format '%zd' expects argument of type 'signed size_t', but argument 9 has type 'long int' [-Werror=format=] _("%s: value for '%s' parameter must be in range %zd:%zd"),
In context, it is because we are using SSIZE_MAX as the argument paired to %zd.
Technically, the standards documents do NOT require ssize_t to have any relation to size_t, and thus there is NO portable way to pass ssize_t values to printf() without a cast; but in practice, most systems are sane enough that 'ssize_t' is the same type as 'signed size_t', as requested by gcc. This includes 32-bit glibc (where size_t is unsigned int, and ssize_t is int).
But it turns out it is a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13575 - SSIZE_MAX must have type ssize_t, and glibc is at fault for defining it as a 'long' value even when ssize_t is an 'int'.
Once gnulib works around it, I'll update libvirt's gnulib submodule to fix the libvirt build on 32-bit Linux again.
Should we just add a cast temporarily ?
Doesn't scale as nicely, but yes, that's a reasonable temporary workaround. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (2)
-
Daniel P. Berrange -
Eric Blake