2:56 a.m.
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
3:48 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
10:26 a.m.
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
2:18 p.m.
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
5:33 p.m.
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
4:05 a.m.
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
12:31 p.m.
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
4976
days inactive
4979
days old
6 comments
3 participants
participants (3)
-
Eric Blake -
Jiri Denemark -
Wen Congyang