On 08/24/2012 09:49 AM, Thomas Graf wrote: > It's a static inline which I guess is the problem here. Laine, you Actually, Viktor hit the problem; Laine couldn't reproduce, so it is probably Viktor with the older header. > are probably using a libnl version which does not include the commit > below. Ah, that rings a bell, I knew I'd seen this issue before. I'm actually surprised it STILL hasn't been fixed in Ubuntu, and maybe it's time to apply the workaround below as a build-breaker fix (I think I've posted it on list before, but never committed it). > > Why is the compiler not OK with this? Because C99 changed the meaning of 'extern inline' from what it used to be in older gcc compilers. You are using a libnl so old that it expects the older gcc semantics > -extern inline void * nl_object_priv(struct nl_object *); where 'extern inline' meant that the function must always be inlined, but on a system with newer gcc, you get C99 semantics. C99 6.7.4 p. 6 states that requires that "For a function with external linkage, the following restrictions apply: If a function is declared with an inline function specifier, then it shall also be defined in the same translation unit.", which means a forward declaration of an 'extern inline' function without a corresponding function body is a violation that the compiler must diagnose. diff --git i/src/util/virnetlink.h w/src/util/virnetlink.h index 1982dae..82154de 100644 --- i/src/util/virnetlink.h +++ w/src/util/virnetlink.h @@ -26,7 +26,11 @@ # if defined(__linux__) && defined(HAVE_LIBNL) +/* Work around a bug where older libnl-1 headers expected older gcc + * semantics of 'extern inline' that conflict with C99 semantics. */ +# define inline # include <netlink/msg.h> +# undef inline # else -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list