[libvirt] [PATCH] build: mark conditionally unused variables
These fixes solve a compilation failure on FreeBSD: util/virnetdevtap.c: In function 'virNetDevTapGetName': util/virnetdevtap.c:56: warning: unused parameter 'tapfd' [-Wunused-parameter] util/virnetdevtap.c:56: warning: unused parameter 'ifname' [-Wunused-parameter] * src/util/virnetdevtap.c (virNetDevTapGetName): Add attributes when TUNGETIFF is not present. Signed-off-by: Eric Blake <eblake@redhat.com> --- Pushing under the build-breaker rule. src/util/virnetdevtap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c index fac95ec..7d77f81 100644 --- a/src/util/virnetdevtap.c +++ b/src/util/virnetdevtap.c @@ -53,7 +53,7 @@ * Returns 0 if the interface name is successfully queried, -1 otherwise */ int -virNetDevTapGetName(int tapfd, char **ifname) +virNetDevTapGetName(int tapfd ATTRIBUTE_UNUSED, char **ifname ATTRIBUTE_UNUSED) { #ifdef TUNGETIFF struct ifreq ifr; -- 1.8.1.4
Eric Blake wrote:
These fixes solve a compilation failure on FreeBSD:
util/virnetdevtap.c: In function 'virNetDevTapGetName': util/virnetdevtap.c:56: warning: unused parameter 'tapfd' [-Wunused-parameter] util/virnetdevtap.c:56: warning: unused parameter 'ifname' [-Wunused-parameter]
* src/util/virnetdevtap.c (virNetDevTapGetName): Add attributes when TUNGETIFF is not present.
Thanks for that fix as well. Can you actually compile it successfully without '--disable-werror'? It fails for me because of gcrypt.h: http://people.freebsd.org/~novel/misc/libvirt_gcrypt_warns.txt When configured with '--without-gnutls', it fails again in remote_protocol.c: http://people.freebsd.org/~novel/misc/libvirt_remote_protocol_warns.txt Going further and disabling remote results in another failure: http://people.freebsd.org/~novel/misc/libvirt_node_devices_warns.txt Roman Bogorodskiy
On 05/02/2013 06:38 AM, Roman Bogorodskiy wrote:
Eric Blake wrote:
These fixes solve a compilation failure on FreeBSD:
util/virnetdevtap.c: In function 'virNetDevTapGetName': util/virnetdevtap.c:56: warning: unused parameter 'tapfd' [-Wunused-parameter] util/virnetdevtap.c:56: warning: unused parameter 'ifname' [-Wunused-parameter]
* src/util/virnetdevtap.c (virNetDevTapGetName): Add attributes when TUNGETIFF is not present.
Thanks for that fix as well.
Can you actually compile it successfully without '--disable-werror'?
Looks like I skipped a few files: $ ./config.status --version | head -n3 libvirt config.status 1.0.5 configured by ./configure, generated by GNU Autoconf 2.68, with options "'-C' 'CFLAGS=-g' '--without-network'" Maybe I should try again and see how omitting --without-network fares.
It fails for me because of gcrypt.h:
http://people.freebsd.org/~novel/misc/libvirt_gcrypt_warns.txt
CC libvirt_driver_la-libvirt.lo cc1: warnings being treated as errors In file included from libvirt.c:58: /usr/local/include/gcrypt.h:1336: warning: 'gcry_ac_io_mode_t' is deprecated [-Wdeprecated-declarations] /usr/local/include/gcrypt.h:1337: warning: 'gcry_ac_io_type_t' is deprecated [-Wdeprecated-declarations] ... lots more deprecation warnings /usr/local often implies a self-built gcrypt; but then I just noticed that my BSD VM has that file as well (I guess that's what you get when using BSD ports) - what version are you using? And what version of gcc, so that we can figure out how to disable deprecation warnings from system headers? For that matter, what is in your file around line 1336, since my copy of the file was not producing deprecation warnings for me, and does not contain 'gcry_ac_io_mode_t' near line 1336.
When configured with '--without-gnutls', it fails again in remote_protocol.c:
http://people.freebsd.org/~novel/misc/libvirt_remote_protocol_warns.txt
Going further and disabling remote results in another failure:
http://people.freebsd.org/~novel/misc/libvirt_node_devices_warns.txt
I'll reply to these in separate email. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 05/02/2013 06:38 AM, Roman Bogorodskiy wrote:
Eric Blake wrote:
These fixes solve a compilation failure on FreeBSD:
util/virnetdevtap.c: In function 'virNetDevTapGetName': util/virnetdevtap.c:56: warning: unused parameter 'tapfd' [-Wunused-parameter] util/virnetdevtap.c:56: warning: unused parameter 'ifname' [-Wunused-parameter]
* src/util/virnetdevtap.c (virNetDevTapGetName): Add attributes when TUNGETIFF is not present.
Thanks for that fix as well.
Can you actually compile it successfully without '--disable-werror'?
Looks like I skipped a few files:
$ ./config.status --version | head -n3 libvirt config.status 1.0.5 configured by ./configure, generated by GNU Autoconf 2.68, with options "'-C' 'CFLAGS=-g' '--without-network'"
Maybe I should try again and see how omitting --without-network fares.
It fails for me because of gcrypt.h:
http://people.freebsd.org/~novel/misc/libvirt_gcrypt_warns.txt
CC libvirt_driver_la-libvirt.lo cc1: warnings being treated as errors In file included from libvirt.c:58: /usr/local/include/gcrypt.h:1336: warning: 'gcry_ac_io_mode_t' is deprecated [-Wdeprecated-declarations] /usr/local/include/gcrypt.h:1337: warning: 'gcry_ac_io_type_t' is deprecated [-Wdeprecated-declarations] ... lots more deprecation warnings
/usr/local often implies a self-built gcrypt; but then I just noticed that my BSD VM has that file as well (I guess that's what you get when using BSD ports) - what version are you using? And what version of gcc, so that we can figure out how to disable deprecation warnings from system headers? For that matter, what is in your file around line 1336, since my copy of the file was not producing deprecation warnings for me, and does not contain 'gcry_ac_io_mode_t' near line 1336.
Indeed, FreeBSD ports install things to /usr/local by default. I'm using gcrypt 1.5.0. Relevant part of gcrypt.h: 1333 typedef struct gcry_ac_io 1334 { 1335 /* This is an INTERNAL structure, do NOT use manually. */ 1336 gcry_ac_io_mode_t mode _GCRY_ATTR_INTERNAL; 1337 gcry_ac_io_type_t type _GCRY_ATTR_INTERNAL; 1338 union .... gcc version 4.2.1 20070831 patched [FreeBSD] Roman Bogorodskiy
On 05/02/2013 09:32 PM, Roman Bogorodskiy wrote:
Can you actually compile it successfully without '--disable-werror'?
Looks like I skipped a few files:
$ ./config.status --version | head -n3 libvirt config.status 1.0.5 configured by ./configure, generated by GNU Autoconf 2.68, with options "'-C' 'CFLAGS=-g' '--without-network'"
Maybe I should try again and see how omitting --without-network fares.
It fails for me because of gcrypt.h:
http://people.freebsd.org/~novel/misc/libvirt_gcrypt_warns.txt
CC libvirt_driver_la-libvirt.lo cc1: warnings being treated as errors In file included from libvirt.c:58: /usr/local/include/gcrypt.h:1336: warning: 'gcry_ac_io_mode_t' is deprecated [-Wdeprecated-declarations]
Okay, I updated my Ports repository on my FreeBSD vm, and I'm seeing this same sort of failure failure with gcc 4.2.1 and gcrypt 1.5.2 (wow - Fedora rawhide still only ships with gcrypt 1.5.1).
I'm using gcrypt 1.5.0.
Relevant part of gcrypt.h:
1333 typedef struct gcry_ac_io 1334 { 1335 /* This is an INTERNAL structure, do NOT use manually. */ 1336 gcry_ac_io_mode_t mode _GCRY_ATTR_INTERNAL; 1337 gcry_ac_io_type_t type _GCRY_ATTR_INTERNAL; 1338 union
The sad part is that we aren't even using the deprecated symbols - their mere inclusion in the installed header is provoking the problems. It looks like newer gcc is a bit more tolerant (that is, this is a shortcoming of FreeBSD's use of an older compiler).
....
gcc version 4.2.1 20070831 patched [FreeBSD]
I'm trying to come up with the best workaround (perhaps disabling -Wdeprecated-declarations if gcrypt.h exists but provokes compiler warnings). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 05/02/2013 09:32 PM, Roman Bogorodskiy wrote:
Can you actually compile it successfully without '--disable-werror'?
Looks like I skipped a few files:
$ ./config.status --version | head -n3 libvirt config.status 1.0.5 configured by ./configure, generated by GNU Autoconf 2.68, with options "'-C' 'CFLAGS=-g' '--without-network'"
Maybe I should try again and see how omitting --without-network fares.
It fails for me because of gcrypt.h:
http://people.freebsd.org/~novel/misc/libvirt_gcrypt_warns.txt
CC libvirt_driver_la-libvirt.lo cc1: warnings being treated as errors In file included from libvirt.c:58: /usr/local/include/gcrypt.h:1336: warning: 'gcry_ac_io_mode_t' is deprecated [-Wdeprecated-declarations]
Okay, I updated my Ports repository on my FreeBSD vm, and I'm seeing this same sort of failure failure with gcc 4.2.1 and gcrypt 1.5.2 (wow - Fedora rawhide still only ships with gcrypt 1.5.1).
I'm using gcrypt 1.5.0.
Relevant part of gcrypt.h:
1333 typedef struct gcry_ac_io 1334 { 1335 /* This is an INTERNAL structure, do NOT use manually. */ 1336 gcry_ac_io_mode_t mode _GCRY_ATTR_INTERNAL; 1337 gcry_ac_io_type_t type _GCRY_ATTR_INTERNAL; 1338 union
The sad part is that we aren't even using the deprecated symbols - their mere inclusion in the installed header is provoking the problems. It looks like newer gcc is a bit more tolerant (that is, this is a shortcoming of FreeBSD's use of an older compiler).
....
gcc version 4.2.1 20070831 patched [FreeBSD]
I'm trying to come up with the best workaround (perhaps disabling -Wdeprecated-declarations if gcrypt.h exists but provokes compiler warnings).
I have tried this fix and it works for me: diff --git a/configure.ac b/configure.ac index 53f78de..4a813cc 100644 --- a/configure.ac +++ b/configure.ac @@ -1090,6 +1090,10 @@ if test "x$with_gnutls" != "xno"; then dnl it explicitly for the calls to gcry_control/check_version GNUTLS_LIBS="$GNUTLS_LIBS -lgcrypt" + dnl We're not using gcrypt deprecated features so define GCRYPT_NO_DEPRECATED + dnl to avoid deprecated warnings + GNUTLS_CFLAGS="$GNUTLS_CFLAGS -DGCRYPT_NO_DEPRECATED" + with_gnutls=yes fi Roman Bogorodskiy
On 05/11/2013 08:27 AM, Roman Bogorodskiy wrote:
The sad part is that we aren't even using the deprecated symbols - their mere inclusion in the installed header is provoking the problems. It looks like newer gcc is a bit more tolerant (that is, this is a shortcoming of FreeBSD's use of an older compiler).
I have tried this fix and it works for me:
diff --git a/configure.ac b/configure.ac index 53f78de..4a813cc 100644 --- a/configure.ac +++ b/configure.ac @@ -1090,6 +1090,10 @@ if test "x$with_gnutls" != "xno"; then dnl it explicitly for the calls to gcry_control/check_version GNUTLS_LIBS="$GNUTLS_LIBS -lgcrypt"
+ dnl We're not using gcrypt deprecated features so define GCRYPT_NO_DEPRECATED + dnl to avoid deprecated warnings + GNUTLS_CFLAGS="$GNUTLS_CFLAGS -DGCRYPT_NO_DEPRECATED"
Cool. I'm trying to get a Fedora rawhide VM going (since it has libgcrypt-1.5.2) and verify that it works there as well, and then I'll probably apply this as a formal patch in your name if I don't find any issues in my testing. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 05/13/2013 09:46 AM, Eric Blake wrote:
On 05/11/2013 08:27 AM, Roman Bogorodskiy wrote:
The sad part is that we aren't even using the deprecated symbols - their mere inclusion in the installed header is provoking the problems. It looks like newer gcc is a bit more tolerant (that is, this is a shortcoming of FreeBSD's use of an older compiler).
I have tried this fix and it works for me:
diff --git a/configure.ac b/configure.ac index 53f78de..4a813cc 100644 --- a/configure.ac +++ b/configure.ac @@ -1090,6 +1090,10 @@ if test "x$with_gnutls" != "xno"; then dnl it explicitly for the calls to gcry_control/check_version GNUTLS_LIBS="$GNUTLS_LIBS -lgcrypt"
+ dnl We're not using gcrypt deprecated features so define GCRYPT_NO_DEPRECATED + dnl to avoid deprecated warnings + GNUTLS_CFLAGS="$GNUTLS_CFLAGS -DGCRYPT_NO_DEPRECATED"
Cool. I'm trying to get a Fedora rawhide VM going (since it has libgcrypt-1.5.2) and verify that it works there as well, and then I'll probably apply this as a formal patch in your name if I don't find any issues in my testing.
Now pushed. I'm still building with CFLAGS=-Wno-error to work past some other issues, but this one should now be fixed. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 05/13/2013 09:46 AM, Eric Blake wrote:
On 05/11/2013 08:27 AM, Roman Bogorodskiy wrote:
The sad part is that we aren't even using the deprecated symbols - their mere inclusion in the installed header is provoking the problems. It looks like newer gcc is a bit more tolerant (that is, this is a shortcoming of FreeBSD's use of an older compiler).
I have tried this fix and it works for me:
diff --git a/configure.ac b/configure.ac index 53f78de..4a813cc 100644 --- a/configure.ac +++ b/configure.ac @@ -1090,6 +1090,10 @@ if test "x$with_gnutls" != "xno"; then dnl it explicitly for the calls to gcry_control/check_version GNUTLS_LIBS="$GNUTLS_LIBS -lgcrypt"
+ dnl We're not using gcrypt deprecated features so define GCRYPT_NO_DEPRECATED + dnl to avoid deprecated warnings + GNUTLS_CFLAGS="$GNUTLS_CFLAGS -DGCRYPT_NO_DEPRECATED"
Cool. I'm trying to get a Fedora rawhide VM going (since it has libgcrypt-1.5.2) and verify that it works there as well, and then I'll probably apply this as a formal patch in your name if I don't find any issues in my testing.
Now pushed. I'm still building with CFLAGS=-Wno-error to work past some other issues, but this one should now be fixed.
Thanks. By the way, it builds fine with -Werror with clang with Daniel's patches.
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Roman Bogorodskiy
On 05/02/2013 06:38 AM, Roman Bogorodskiy wrote:
When configured with '--without-gnutls', it fails again in remote_protocol.c:
http://people.freebsd.org/~novel/misc/libvirt_remote_protocol_warns.txt
CC libvirt_driver_remote_la-remote_protocol.lo cc1: warnings being treated as errors ./remote/remote_protocol.c: In function 'xdr_remote_node_get_cpu_stats_ret': ./remote/remote_protocol.c:530: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] I suspect this is a macro expansion triggering the actual warning; can you determine what the preprocessed text is that is behind this warning? I bet we can fix it in one or two places for all of the warnings triggered on this file.
Going further and disabling remote results in another failure:
http://people.freebsd.org/~novel/misc/libvirt_node_devices_warns.txt
node_device/node_device_driver.c: In function 'update_caps': node_device/node_device_driver.c:51: warning: statement with no effect That comes from: detect_scsi_host_caps(&dev->def->caps->data); which in turn shows up as this in node_device_driver.h: # define detect_scsi_host_caps(d) (-1) I don't know why I'm not seeing the warning, but that one's easy to fix - I can try to patch that one. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (2)
-
Eric Blake -
Roman Bogorodskiy