[libvirt] Magic error introduced by commit f09accc
Hi all, After commit f09accc (buf: add virBufferVasprintf) libvirt no longer compiles with -Werror because of the following error: CC libvirt_util_la-macvtap.lo cc1: warnings being treated as errors /usr/include/netlink/object.h:58: error: inline function 'nl_object_priv' declared but never defined I must admit I don't understand why including stdarg.h (which seems to be the only change visible in macvtap.c) results in this warning. Does anyone have an idea? Jirka
At 05/06/2011 03:56 PM, Jiri Denemark Write:
Hi all,
After commit f09accc (buf: add virBufferVasprintf) libvirt no longer compiles with -Werror because of the following error:
CC libvirt_util_la-macvtap.lo cc1: warnings being treated as errors /usr/include/netlink/object.h:58: error: inline function 'nl_object_priv' declared but never defined
I use -Werror, but do not meet this problem. My steps to build: 1. CFLAGS=-Werror 2. export CFLAGS 3. ./configure 4. make
I must admit I don't understand why including stdarg.h (which seems to be the only change visible in macvtap.c) results in this warning.
Does anyone have an idea?
Jirka
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 05/06/2011 01:56 AM, Jiri Denemark wrote:
Hi all,
After commit f09accc (buf: add virBufferVasprintf) libvirt no longer compiles with -Werror because of the following error:
CC libvirt_util_la-macvtap.lo cc1: warnings being treated as errors /usr/include/netlink/object.h:58: error: inline function 'nl_object_priv' declared but never defined
I must admit I don't understand why including stdarg.h (which seems to be the only change visible in macvtap.c) results in this warning.
Does anyone have an idea?
Which version of libnl and gcc? Yes, I know exactly why you are getting the failure. The gnulib stdarg module requires C99 support for va_copy. If this turns on -std=gnu99 in CFLAGS, whereas that compiler flag was not previously present, then you are getting a difference in gcc inline semantics. And if libnl's headers are buggy (or, better put, if they don't properly deal with the fact that older gcc's 'static inline' semantics heavily differ from C99's 'static inline' semantics, and that you have to properly guard the code to get the desired semantics), then that would explain the problem. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, May 06, 2011 at 09:26:57 -0600, Eric Blake wrote:
On 05/06/2011 01:56 AM, Jiri Denemark wrote:
Hi all,
After commit f09accc (buf: add virBufferVasprintf) libvirt no longer compiles with -Werror because of the following error:
CC libvirt_util_la-macvtap.lo cc1: warnings being treated as errors /usr/include/netlink/object.h:58: error: inline function 'nl_object_priv' declared but never defined
I must admit I don't understand why including stdarg.h (which seems to be the only change visible in macvtap.c) results in this warning.
Does anyone have an idea?
Which version of libnl and gcc?
libnl-1.1, gcc-4.4.5 You are right, that the commit results in -std=gnu99 being added to gcc command line. However, the nl_object_priv is declared as extern inline void * nl_object_priv(struct nl_object *); So not 'static inline' but 'extern inline', I guess the issue is the same, right? Jirka
On 05/06/2011 01:18 PM, Jiri Denemark wrote:
I must admit I don't understand why including stdarg.h (which seems to be the only change visible in macvtap.c) results in this warning.
Does anyone have an idea?
Which version of libnl and gcc?
libnl-1.1, gcc-4.4.5
You are right, that the commit results in -std=gnu99 being added to gcc command line. However, the nl_object_priv is declared as
extern inline void * nl_object_priv(struct nl_object *);
So not 'static inline' but 'extern inline', I guess the issue is the same, right?
We discussed more on IRC. The problem is due to a bug in out-of-the-box libnl headers, and has been patched in most distros to just delete the 'inline' as then you don't have to worry about whether you had old or new gcc semantics for 'extern inline'. That is, libvirt could probably work around the issue by doing: #define inline #include <netlink/msg.h> #undef inline in src/util/macvtap.c. However, I don't know if we should do that. In one regards, the only people that ever run into this are those that are using incompatible self-built gcc and libnl (Jirka was testing on a gentoo system), and we're doing the user a favor to have them patch their libnl headers rather than making libvirt work around it. Most distros (including RHEL 5, which stands as the current litmus test of how much workarounds we have to support in libvirt) have already patched the header, or have an old enough gcc that the problem doesn't hit in the first place. And someday, we should be moving on to newer libnl. So unless anyone else speaks up, I won't bother writing a patch for libvirt to work around the libnl bug. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, May 06, 2011 at 16:33:13 -0600, Eric Blake wrote:
On 05/06/2011 01:18 PM, Jiri Denemark wrote: We discussed more on IRC. The problem is due to a bug in out-of-the-box libnl headers, and has been patched in most distros to just delete the 'inline' as then you don't have to worry about whether you had old or new gcc semantics for 'extern inline'. That is, libvirt could probably work around the issue by doing:
#define inline #include <netlink/msg.h> #undef inline
in src/util/macvtap.c.
However, I don't know if we should do that.
I think we shouldn't do this.
In one regards, the only people that ever run into this are those that are using incompatible self-built gcc and libnl (Jirka was testing on a gentoo system), and we're doing the user a favor to have them patch their libnl headers rather than making libvirt work around it. Most distros (including RHEL 5, which stands as the current litmus test of how much workarounds we have to support in libvirt) have already patched the header
And I filed a BZ for gentoo as well: http://bugs.gentoo.org/show_bug.cgi?id=366561 Jirka
On 05/09/2011 03:05 AM, Jiri Denemark wrote:
work around the issue by doing:
#define inline #include <netlink/msg.h> #undef inline
in src/util/macvtap.c.
I think we shouldn't do this.
In one regards, the only people that ever run into this are those that are using incompatible self-built gcc and libnl (Jirka was testing on a gentoo system), and we're doing the user a favor to have them patch their libnl headers rather than making libvirt work around it. Most distros (including RHEL 5, which stands as the current litmus test of how much workarounds we have to support in libvirt) have already patched the header
I stand corrected - Ubuntu is also affected: https://bugs.launchpad.net/ubuntu/+source/libnl/+bug/780044 -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eric Blake -
Jiri Denemark -
Wen Congyang