[libvirt] Start of freeze for libvirt-0.9.8 and availability of rc1
We are now entering the freeze for libvirt-0.9.8 . For portability sake I think adding more support for PPC machines should still be allowed for a few days, as long as it's not impacting too much of the common code. I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.8-rc1.tar.gz and the git tree is tagged. I think I will make an rc2 on Mon or Thu and then try to make the release around Thursday next week if things looks good. Please give it a try ! thanks in advance, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Thu, Dec 01, 2011 at 01:48:46PM +0800, Daniel Veillard thus spake:
We are now entering the freeze for libvirt-0.9.8 . For portability sake I think adding more support for PPC machines should still be allowed for a few days, as long as it's not impacting too much of the common code.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.8-rc1.tar.gz and the git tree is tagged.
I think I will make an rc2 on Mon or Thu and then try to make the release around Thursday next week if things looks good.
Please give it a try !
thanks in advance,
Daniel
-- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
failed on freebsd: -C libvirt_util_la-virnetdev.lo util/virnetdev.c: In function 'virNetDevExists': util/virnetdev.c:103: error: storage size of 'ifr' isn't known util/virnetdev.c:105: warning: implicit declaration of function 'virNetDevSetupControl' util/virnetdev.c:105: warning: nested extern declaration of 'virNetDevSetupControl' [-Wnested-externs] util/virnetdev.c:108: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:103: warning: unused variable 'ifr' [-Wunused-variable] util/virnetdev.c: In function 'virNetDevGetMTU': util/virnetdev.c:336: error: storage size of 'ifr' isn't known util/virnetdev.c:341: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:336: warning: unused variable 'ifr' [-Wunused-variable] util/virnetdev.c: In function 'virNetDevSetMTU': util/virnetdev.c:380: error: storage size of 'ifr' isn't known util/virnetdev.c:387: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:380: warning: unused variable 'ifr' [-Wunused-variable] util/virnetdev.c: In function 'virNetDevSetName': util/virnetdev.c:477: error: storage size of 'ifr' isn't known util/virnetdev.c:489: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:477: warning: unused variable 'ifr' [-Wunused-variable] util/virnetdev.c: In function 'virNetDevSetOnline': util/virnetdev.c:528: error: storage size of 'ifr' isn't known util/virnetdev.c:534: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:542: error: 'IFF_UP' undeclared (first use in this function) util/virnetdev.c:542: error: (Each undeclared identifier is reported only once util/virnetdev.c:542: error: for each function it appears in.) util/virnetdev.c:548: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:528: warning: unused variable 'ifr' [-Wunused-variable] util/virnetdev.c: In function 'virNetDevIsOnline': util/virnetdev.c:589: error: storage size of 'ifr' isn't known util/virnetdev.c:594: error: invalid application of 'sizeof' to incomplete type 'struct ifreq' util/virnetdev.c:601: error: 'IFF_UP' undeclared (first use in this function) util/virnetdev.c:589: warning: unused variable 'ifr' [-Wunused-variable] gmake[3]: *** [libvirt_util_la-virnetdev.lo] Error 1 gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.8/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.8/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.8' gmake: *** [all] Error 2 *** Error code 1 Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
From: "Daniel P. Berrange" <berrange@redhat.com> This ought to fix the build if you have net/if.h but do not have struct ifreq * configure.ac: Check for struct ifreq in net/if.h * src/util/virnetdev.c: Conditionalize to avoid use of struct ifreq if it does not exist --- configure.ac | 14 ++++++++++++++ src/util/virnetdev.c | 42 +++++++++++++++++++++--------------------- 2 files changed, 35 insertions(+), 21 deletions(-) diff --git a/configure.ac b/configure.ac index de2f379..77e5cc9 100644 --- a/configure.ac +++ b/configure.ac @@ -163,6 +163,20 @@ AC_CHECK_HEADERS([pwd.h paths.h regex.h sys/un.h \ sys/un.h sys/syscall.h netinet/tcp.h ifaddrs.h libtasn1.h \ net/if.h]) +AC_MSG_CHECKING([for struct ifreq in net/if.h]) +AC_COMPILE_IFELSE([AC_LANG_PROGRAM( + [[ + #include <net/if.h> + ]], + [[ + struct ifreq ifr; + ]])],[ + AC_DEFINE([HAVE_STRUCT_IFREQ],[],[Defined if struct ifreq existsin net/if.h]) + AC_MSG_RESULT([yes]) + ],[ + AC_MSG_RESULT([yes]) + ]) + dnl Our only use of libtasn1.h is in the testsuite, and can be skipped dnl if the header is not present. Assume -ltasn1 is present if the dnl header could be found. diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 86196a1..3187215 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -45,7 +45,7 @@ virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \ __FUNCTION__, __LINE__, __VA_ARGS__) -#ifdef HAVE_NET_IF_H +#if defined(HAVE_STRUCT_IFREQ) static int virNetDevSetupControlFull(const char *ifname, struct ifreq *ifr, int domain, @@ -87,7 +87,7 @@ static int virNetDevSetupControl(const char *ifname, #endif -#ifdef SIOCGIFFLAGS +#if defined(SIOCGIFFLAGS) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevExists: * @ifname @@ -130,7 +130,7 @@ int virNetDevExists(const char *ifname) #endif -#ifdef SIOCGIFHWADDR +#if defined(SIOCGIFHWADDR) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetMAC: * @ifname: interface name to set MTU for @@ -186,7 +186,7 @@ int virNetDevSetMAC(const char *ifname, #endif -#ifdef SIOCGIFHWADDR +#if defined(SIOCGIFHWADDR) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevGetMAC: * @ifname: interface name to set MTU for @@ -320,7 +320,7 @@ virNetDevRestoreMacAddress(const char *linkdev, } -#ifdef SIOCGIFMTU +#if defined(SIOCGIFMTU) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevGetMTU: * @ifname: interface name get MTU for @@ -362,7 +362,7 @@ int virNetDevGetMTU(const char *ifname) #endif -#ifdef SIOCSIFMTU +#if defined(SIOCSIFMTU) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetMTU: * @ifname: interface name to set MTU for @@ -460,7 +460,7 @@ int virNetDevSetNamespace(const char *ifname, int pidInNs) return rc; } -#ifdef SIOCSIFNAME +#if defined(SIOCSIFNAME) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetName: * @ifname: name of device @@ -510,7 +510,7 @@ int virNetDevSetName(const char* ifname, const char *newifname) #endif -#ifdef SIOCSIFFLAGS +#if defined(SIOCSIFFLAGS) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetOnline: * @ifname: the interface name @@ -571,7 +571,7 @@ int virNetDevSetOnline(const char *ifname, #endif -#ifdef SIOCGIFFLAGS +#if defined(SIOCGIFFLAGS) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevIsOnline: * @ifname: the interface name @@ -626,7 +626,7 @@ int virNetDevIsOnline(const char *ifname, * * Returns 0 on success, -1 on failure */ -#ifdef __linux__ +#if defined(SIOCGIFINDEX) && defined(HAVE_STRUCT_IFREQ) int virNetDevGetIndex(const char *ifname, int *ifindex) { int ret = -1; @@ -662,7 +662,7 @@ cleanup: VIR_FORCE_CLOSE(fd); return ret; } -#else /* ! __linux__ */ +#else /* ! SIOCGIFINDEX */ int virNetDevGetIndex(const char *ifname ATTRIBUTE_UNUSED, int *ifindex ATTRIBUTE_UNUSED) { @@ -670,10 +670,10 @@ int virNetDevGetIndex(const char *ifname ATTRIBUTE_UNUSED, _("Unable to get interface index on this platform")); return -1; } -#endif /* ! __linux__ */ +#endif /* ! SIOCGIFINDEX */ -#ifdef __linux__ +#if defined(SIOCGIFVLAN) && defined(HAVE_STRUCT_IFREQ) int virNetDevGetVLanID(const char *ifname, int *vlanid) { struct vlan_ioctl_args vlanargs = { @@ -709,7 +709,7 @@ int virNetDevGetVLanID(const char *ifname, int *vlanid) return ret; } -#else /* ! __linux__ */ +#else /* ! SIOCGIFVLAN */ int virNetDevGetVLanID(const char *ifname ATTRIBUTE_UNUSED, int *vlanid ATTRIBUTE_UNUSED) { @@ -717,7 +717,7 @@ int virNetDevGetVLanID(const char *ifname ATTRIBUTE_UNUSED, _("Unable to get VLAN on this platform")); return -1; } -#endif /* ! __linux__ */ +#endif /* ! SIOCGIFVLAN */ @@ -816,7 +816,7 @@ cleanup: * * Returns 0 on success, -errno on failure. */ -#ifdef __linux__ +#if defined(SIOCGIFADDR) && defined(HAVE_STRUCT_IFREQ) int virNetDevGetIPv4Address(const char *ifname, virSocketAddrPtr addr) { @@ -846,7 +846,7 @@ cleanup: return ret; } -#else +#else /* ! SIOCGIFADDR */ int virNetDevGetIPv4Address(const char *ifname ATTRIBUTE_UNUSED, virSocketAddrPtr addr ATTRIBUTE_UNUSED) @@ -856,7 +856,7 @@ int virNetDevGetIPv4Address(const char *ifname ATTRIBUTE_UNUSED, return -1; } -#endif /* __linux__ */ +#endif /* ! SIOCGIFADDR */ /** @@ -871,7 +871,7 @@ int virNetDevGetIPv4Address(const char *ifname ATTRIBUTE_UNUSED, * * Returns 1 if the config matches, 0 if the config does not match, or interface does not exist, -1 on error */ -#ifdef __linux__ +#if defined(HAVE_STRUCT_IFREQ) int virNetDevValidateConfig(const char *ifname, const unsigned char *macaddr, int ifindex) { @@ -924,7 +924,7 @@ int virNetDevValidateConfig(const char *ifname, VIR_FORCE_CLOSE(fd); return ret; } -#else /* ! __linux__ */ +#else /* ! HAVE_STRUCT_IFREQ */ int virNetDevValidateConfig(const char *ifname ATTRIBUTE_UNUSED, const unsigned char *macaddr ATTRIBUTE_UNUSED, int ifindex ATTRIBUTE_UNUSED) @@ -933,7 +933,7 @@ int virNetDevValidateConfig(const char *ifname ATTRIBUTE_UNUSED, _("Unable to check interface config on this platform")); return -1; } -#endif /* ! __linux__ */ +#endif /* ! HAVE_STRUCT_IFREQ */ #ifdef __linux__ -- 1.7.6.4
On Thu, Dec 01, 2011 at 01:31:18PM +0000, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
This ought to fix the build if you have net/if.h but do not have struct ifreq
* configure.ac: Check for struct ifreq in net/if.h * src/util/virnetdev.c: Conditionalize to avoid use of struct ifreq if it does not exist --- configure.ac | 14 ++++++++++++++ src/util/virnetdev.c | 42 +++++++++++++++++++++--------------------- 2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/configure.ac b/configure.ac index de2f379..77e5cc9 100644 --- a/configure.ac +++ b/configure.ac @@ -163,6 +163,20 @@ AC_CHECK_HEADERS([pwd.h paths.h regex.h sys/un.h \ sys/un.h sys/syscall.h netinet/tcp.h ifaddrs.h libtasn1.h \ net/if.h])
+AC_MSG_CHECKING([for struct ifreq in net/if.h]) +AC_COMPILE_IFELSE([AC_LANG_PROGRAM( + [[ + #include <net/if.h> + ]], + [[ + struct ifreq ifr; + ]])],[ + AC_DEFINE([HAVE_STRUCT_IFREQ],[],[Defined if struct ifreq existsin net/if.h]) + AC_MSG_RESULT([yes]) + ],[ + AC_MSG_RESULT([yes]) + ]) + dnl Our only use of libtasn1.h is in the testsuite, and can be skipped dnl if the header is not present. Assume -ltasn1 is present if the dnl header could be found. diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 86196a1..3187215 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -45,7 +45,7 @@ virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \ __FUNCTION__, __LINE__, __VA_ARGS__)
-#ifdef HAVE_NET_IF_H +#if defined(HAVE_STRUCT_IFREQ) static int virNetDevSetupControlFull(const char *ifname, struct ifreq *ifr, int domain, @@ -87,7 +87,7 @@ static int virNetDevSetupControl(const char *ifname, #endif
-#ifdef SIOCGIFFLAGS +#if defined(SIOCGIFFLAGS) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevExists: * @ifname @@ -130,7 +130,7 @@ int virNetDevExists(const char *ifname) #endif
-#ifdef SIOCGIFHWADDR +#if defined(SIOCGIFHWADDR) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetMAC: * @ifname: interface name to set MTU for @@ -186,7 +186,7 @@ int virNetDevSetMAC(const char *ifname, #endif
-#ifdef SIOCGIFHWADDR +#if defined(SIOCGIFHWADDR) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevGetMAC: * @ifname: interface name to set MTU for @@ -320,7 +320,7 @@ virNetDevRestoreMacAddress(const char *linkdev, }
-#ifdef SIOCGIFMTU +#if defined(SIOCGIFMTU) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevGetMTU: * @ifname: interface name get MTU for @@ -362,7 +362,7 @@ int virNetDevGetMTU(const char *ifname) #endif
-#ifdef SIOCSIFMTU +#if defined(SIOCSIFMTU) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetMTU: * @ifname: interface name to set MTU for @@ -460,7 +460,7 @@ int virNetDevSetNamespace(const char *ifname, int pidInNs) return rc; }
-#ifdef SIOCSIFNAME +#if defined(SIOCSIFNAME) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetName: * @ifname: name of device @@ -510,7 +510,7 @@ int virNetDevSetName(const char* ifname, const char *newifname) #endif
-#ifdef SIOCSIFFLAGS +#if defined(SIOCSIFFLAGS) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevSetOnline: * @ifname: the interface name @@ -571,7 +571,7 @@ int virNetDevSetOnline(const char *ifname, #endif
-#ifdef SIOCGIFFLAGS +#if defined(SIOCGIFFLAGS) && defined(HAVE_STRUCT_IFREQ) /** * virNetDevIsOnline: * @ifname: the interface name @@ -626,7 +626,7 @@ int virNetDevIsOnline(const char *ifname, * * Returns 0 on success, -1 on failure */ -#ifdef __linux__ +#if defined(SIOCGIFINDEX) && defined(HAVE_STRUCT_IFREQ) int virNetDevGetIndex(const char *ifname, int *ifindex) { int ret = -1; @@ -662,7 +662,7 @@ cleanup: VIR_FORCE_CLOSE(fd); return ret; } -#else /* ! __linux__ */ +#else /* ! SIOCGIFINDEX */ int virNetDevGetIndex(const char *ifname ATTRIBUTE_UNUSED, int *ifindex ATTRIBUTE_UNUSED) { @@ -670,10 +670,10 @@ int virNetDevGetIndex(const char *ifname ATTRIBUTE_UNUSED, _("Unable to get interface index on this platform")); return -1; } -#endif /* ! __linux__ */ +#endif /* ! SIOCGIFINDEX */
-#ifdef __linux__ +#if defined(SIOCGIFVLAN) && defined(HAVE_STRUCT_IFREQ) int virNetDevGetVLanID(const char *ifname, int *vlanid) { struct vlan_ioctl_args vlanargs = { @@ -709,7 +709,7 @@ int virNetDevGetVLanID(const char *ifname, int *vlanid)
return ret; } -#else /* ! __linux__ */ +#else /* ! SIOCGIFVLAN */ int virNetDevGetVLanID(const char *ifname ATTRIBUTE_UNUSED, int *vlanid ATTRIBUTE_UNUSED) { @@ -717,7 +717,7 @@ int virNetDevGetVLanID(const char *ifname ATTRIBUTE_UNUSED, _("Unable to get VLAN on this platform")); return -1; } -#endif /* ! __linux__ */ +#endif /* ! SIOCGIFVLAN */
@@ -816,7 +816,7 @@ cleanup: * * Returns 0 on success, -errno on failure. */ -#ifdef __linux__ +#if defined(SIOCGIFADDR) && defined(HAVE_STRUCT_IFREQ) int virNetDevGetIPv4Address(const char *ifname, virSocketAddrPtr addr) { @@ -846,7 +846,7 @@ cleanup: return ret; }
-#else +#else /* ! SIOCGIFADDR */
int virNetDevGetIPv4Address(const char *ifname ATTRIBUTE_UNUSED, virSocketAddrPtr addr ATTRIBUTE_UNUSED) @@ -856,7 +856,7 @@ int virNetDevGetIPv4Address(const char *ifname ATTRIBUTE_UNUSED, return -1; }
-#endif /* __linux__ */ +#endif /* ! SIOCGIFADDR */
/** @@ -871,7 +871,7 @@ int virNetDevGetIPv4Address(const char *ifname ATTRIBUTE_UNUSED, * * Returns 1 if the config matches, 0 if the config does not match, or interface does not exist, -1 on error */ -#ifdef __linux__ +#if defined(HAVE_STRUCT_IFREQ) int virNetDevValidateConfig(const char *ifname, const unsigned char *macaddr, int ifindex) { @@ -924,7 +924,7 @@ int virNetDevValidateConfig(const char *ifname, VIR_FORCE_CLOSE(fd); return ret; } -#else /* ! __linux__ */ +#else /* ! HAVE_STRUCT_IFREQ */ int virNetDevValidateConfig(const char *ifname ATTRIBUTE_UNUSED, const unsigned char *macaddr ATTRIBUTE_UNUSED, int ifindex ATTRIBUTE_UNUSED) @@ -933,7 +933,7 @@ int virNetDevValidateConfig(const char *ifname ATTRIBUTE_UNUSED, _("Unable to check interface config on this platform")); return -1; } -#endif /* ! __linux__ */ +#endif /* ! HAVE_STRUCT_IFREQ */
#ifdef __linux__ -- 1.7.6.4
ACK, seems this should take care of the reported BSD incompatibility Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 12/01/2011 07:22 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 01:31:18PM +0000, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
This ought to fix the build if you have net/if.h but do not have struct ifreq
ACK, seems this should take care of the reported BSD incompatibility
I've confirmed it on FreeBSD, and am pushing this under the build-breaker rule. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 12/01/2011 01:55 PM, Eric Blake wrote:
On 12/01/2011 07:22 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 01:31:18PM +0000, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
This ought to fix the build if you have net/if.h but do not have struct ifreq
ACK, seems this should take care of the reported BSD incompatibility
I've confirmed it on FreeBSD, and am pushing this under the build-breaker rule.
Alas, the fix is incomplete. Cygwin has struct ifreq but lacks ioctl SIOCSIFHWADDR: util/virnetdev.c: In function 'virNetDevSetupControl': util/virnetdev.c:85:51: error: 'AF_PACKET' undeclared (first use in this function) util/virnetdev.c:85:51: note: each undeclared identifier is reported only once for each function it appears in util/virnetdev.c: In function 'virNetDevSetMAC': util/virnetdev.c:164:19: error: 'SIOCSIFHWADDR' undeclared (first use in this function) util/virnetdev.c: In function 'virNetDevGetIndex': util/virnetdev.c:634:21: error: 'PF_PACKET' undeclared (first use in this function) util/virnetdev.c: In function 'virNetDevSetupControl': util/virnetdev.c:86:1: warning: control reaches end of non-void function [-Wreturn-type] I'm testing a patch to further restrict the condition to just Linux, rather than going off of struct ifreq. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
The RPC fixups needed on Linux are also needed on cygwin, and worked without further tweaking to the list of fixups. Also, unlike BSD, Cygwin exports 'struct ifreq', but unlike Linux, Cygwin lacks the ioctls that we were using 'struct ifreq' to access. This patch allows compilation under cygwin. * src/rpc/genprotocol.pl: Also perform fixups on cygwin. * src/util/virnetdev.c (HAVE_STRUCT_IFREQ): Also require AF_PACKET definition. * src/util/virnetdevbridge.c (virNetDevSetupControlFull): Only compile if SIOCBRADDBR works. --- Pushing under the build-breaker rule. src/rpc/genprotocol.pl | 2 +- src/util/virnetdev.c | 2 ++ src/util/virnetdevbridge.c | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/rpc/genprotocol.pl b/src/rpc/genprotocol.pl index 166508b..7af1b3b 100755 --- a/src/rpc/genprotocol.pl +++ b/src/rpc/genprotocol.pl @@ -31,7 +31,7 @@ open RPCGEN, "-|", $rpcgen, $mode, $xdrdef open TARGET, ">$target" or die "cannot create $target: $!"; -my $fixup = $^O eq "linux"; +my $fixup = $^O eq "linux" || $^O eq "cygwin"; if ($mode eq "-c") { print TARGET "#include <config.h>\n"; diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 3187215..a1c62e3 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -38,6 +38,8 @@ #ifdef __linux__ # include <linux/sockios.h> # include <linux/if_vlan.h> +#elif !defined(AF_PACKET) +# undef HAVE_STRUCT_IFREQ #endif #define VIR_FROM_THIS VIR_FROM_NONE diff --git a/src/util/virnetdevbridge.c b/src/util/virnetdevbridge.c index 0440a73..e246b2c 100644 --- a/src/util/virnetdevbridge.c +++ b/src/util/virnetdevbridge.c @@ -45,7 +45,7 @@ #define VIR_FROM_THIS VIR_FROM_NONE -#ifdef HAVE_NET_IF_H +#if defined(HAVE_NET_IF_H) && defined(SIOCBRADDBR) static int virNetDevSetupControlFull(const char *ifname, struct ifreq *ifr, int domain, -- 1.7.7.3
On Sat, Dec 03, 2011 at 01:03:08PM -0700, Eric Blake wrote:
The RPC fixups needed on Linux are also needed on cygwin, and worked without further tweaking to the list of fixups. Also, unlike BSD, Cygwin exports 'struct ifreq', but unlike Linux, Cygwin lacks the ioctls that we were using 'struct ifreq' to access. This patch allows compilation under cygwin.
* src/rpc/genprotocol.pl: Also perform fixups on cygwin. * src/util/virnetdev.c (HAVE_STRUCT_IFREQ): Also require AF_PACKET definition. * src/util/virnetdevbridge.c (virNetDevSetupControlFull): Only compile if SIOCBRADDBR works. ---
Pushing under the build-breaker rule.
src/rpc/genprotocol.pl | 2 +- src/util/virnetdev.c | 2 ++ src/util/virnetdevbridge.c | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/rpc/genprotocol.pl b/src/rpc/genprotocol.pl index 166508b..7af1b3b 100755 --- a/src/rpc/genprotocol.pl +++ b/src/rpc/genprotocol.pl @@ -31,7 +31,7 @@ open RPCGEN, "-|", $rpcgen, $mode, $xdrdef open TARGET, ">$target" or die "cannot create $target: $!";
-my $fixup = $^O eq "linux"; +my $fixup = $^O eq "linux" || $^O eq "cygwin";
if ($mode eq "-c") { print TARGET "#include <config.h>\n"; diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 3187215..a1c62e3 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -38,6 +38,8 @@ #ifdef __linux__ # include <linux/sockios.h> # include <linux/if_vlan.h> +#elif !defined(AF_PACKET) +# undef HAVE_STRUCT_IFREQ #endif
#define VIR_FROM_THIS VIR_FROM_NONE diff --git a/src/util/virnetdevbridge.c b/src/util/virnetdevbridge.c index 0440a73..e246b2c 100644 --- a/src/util/virnetdevbridge.c +++ b/src/util/virnetdevbridge.c @@ -45,7 +45,7 @@ #define VIR_FROM_THIS VIR_FROM_NONE
-#ifdef HAVE_NET_IF_H +#if defined(HAVE_NET_IF_H) && defined(SIOCBRADDBR) static int virNetDevSetupControlFull(const char *ifname, struct ifreq *ifr, int domain,
ACK 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 11/30/2011 10:48 PM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.8 . For portability sake I think adding more support for PPC machines should still be allowed for a few days, as long as it's not impacting too much of the common code.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.8-rc1.tar.gz and the git tree is tagged.
I think I will make an rc2 on Mon or Thu and then try to make the release around Thursday next week if things looks good.
Please give it a try !
On IRC: eblake DV: it looks like you missed my gnulib update for rc1 - what do we do about that? DV eblake: oops, well let's update in git DV it will be in rc2, as long as there is a release candidate with the update I think it's fine I'll use that to justify pushing my pending gnulib update now. https://www.redhat.com/archives/libvir-list/2011-November/msg01635.html But that means we really are committing to an rc2. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
On 11/30/2011 10:48 PM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.8 . For portability sake I think adding more support for PPC machines should still be allowed for a few days, as long as it's not impacting too much of the common code.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.8-rc1.tar.gz and the git tree is tagged.
I think I will make an rc2 on Mon or Thu and then try to make the release around Thursday next week if things looks good.
Please give it a try !
On IRC:
eblake DV: it looks like you missed my gnulib update for rc1 - what do we do about that? DV eblake: oops, well let's update in git DV it will be in rc2, as long as there is a release candidate with the update I think it's fine
I'll use that to justify pushing my pending gnulib update now. https://www.redhat.com/archives/libvir-list/2011-November/msg01635.html
But that means we really are committing to an rc2.
Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 12/02/2011 01:42 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
On IRC:
eblake DV: it looks like you missed my gnulib update for rc1 - what do we do about that? DV eblake: oops, well let's update in git DV it will be in rc2, as long as there is a release candidate with the update I think it's fine
I'll use that to justify pushing my pending gnulib update now. https://www.redhat.com/archives/libvir-list/2011-November/msg01635.html
But that means we really are committing to an rc2.
Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-)
Daniel
The problem was caused by two threads that both were thinking they are having the buck and entering poll() which caused some clients to hang. It was possible due to a race condition and therefore was not 100% reproducible. It should be fixed now with: http://www.redhat.com/archives/libvir-list/2011-December/msg00116.html Peter
On Fri, Dec 02, 2011 at 02:30:35PM +0100, Peter Krempa wrote:
On 12/02/2011 01:42 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
But that means we really are committing to an rc2.
Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-)
Daniel
The problem was caused by two threads that both were thinking they are having the buck and entering poll() which caused some clients to hang. It was possible due to a race condition and therefore was not 100% reproducible. It should be fixed now with: http://www.redhat.com/archives/libvir-list/2011-December/msg00116.html
Indeed, the current git head works fine again for me, thanks a lot for chasing this :-) So I made an second release candidate available at: ftp://libvirt.org/libvirt/libvirt-0.9.8-rc2.tar.gz along with rpms, I also tagged git with it. Hopefully the builds on BSD and Windows should be fixed, it would be good if it could be tested on OsX and since there was a build done last month on Android, I wonder if this could be done again [1]. thanks everybody ! Daniel [1] maybe we should setup some cross compilation testing like for cygwin... -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Dňa 4.12.2011 9:10, Daniel Veillard wrote / napísal(a):
Indeed, the current git head works fine again for me, thanks a lot for chasing this :-)
So I made an second release candidate available at:
ftp://libvirt.org/libvirt/libvirt-0.9.8-rc2.tar.gz
along with rpms, I also tagged git with it. Hopefully the builds on BSD and Windows should be fixed, it would be good if it could be tested on OsX and since there was a build done last month on Android, I wonder if this could be done again [1].
thanks everybody !
Daniel
[1] maybe we should setup some cross compilation testing like for cygwin...
I tried building rc2 on my macbook and build was successful, but I've got a warning on each file built: cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but not for C cc1: warning: command line option "-Wdeprecated" is valid for C++/ObjC++ but not for C Compiler: Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5664~105/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664) I will investigate if we can do something about it, but the RC2 is working fine. (tested on remote and virtualbox) Peter P.S.: I didn't manage to squeeze in two PythonAPI bindings Eric said were worthy for 0.9.8, but it probably won't be such a tragedy :). (I don't have my ssh key on my laptop).
On 12/04/2011 02:26 AM, Peter Krempa wrote:
I tried building rc2 on my macbook and build was successful, but I've got a warning on each file built:
cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but not for C cc1: warning: command line option "-Wdeprecated" is valid for C++/ObjC++ but not for C
This is a known (and harmless) issue with the gnulib 'manywarnings' module, and only triggers with older versions of gcc. It will probably be resolved in gnulib in time for libvirt 0.9.9, but I don't see us doing anything about it for now (if you don't want the warning, then don't use --enable-compile-warnings with ./autogen.sh or ./configure). -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Mon, Dec 05, 2011 at 09:25:40AM -0700, Eric Blake wrote:
On 12/04/2011 02:26 AM, Peter Krempa wrote:
I tried building rc2 on my macbook and build was successful, but I've got a warning on each file built:
cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but not for C cc1: warning: command line option "-Wdeprecated" is valid for C++/ObjC++ but not for C
This is a known (and harmless) issue with the gnulib 'manywarnings' module, and only triggers with older versions of gcc. It will probably be resolved in gnulib in time for libvirt 0.9.9, but I don't see us doing anything about it for now (if you don't want the warning, then don't use --enable-compile-warnings with ./autogen.sh or ./configure).
Can we workaround it by adding dontwarn="$dontwarn -Wabi" dontwarn="$dontwarn -Wdeprecated" to our m4 config, until such time as we rebase gnulib ? 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 12/05/2011 09:41 AM, Daniel P. Berrange wrote:
On Mon, Dec 05, 2011 at 09:25:40AM -0700, Eric Blake wrote:
On 12/04/2011 02:26 AM, Peter Krempa wrote:
I tried building rc2 on my macbook and build was successful, but I've got a warning on each file built:
cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but not for C cc1: warning: command line option "-Wdeprecated" is valid for C++/ObjC++ but not for C
This is a known (and harmless) issue with the gnulib 'manywarnings' module, and only triggers with older versions of gcc. It will probably be resolved in gnulib in time for libvirt 0.9.9, but I don't see us doing anything about it for now (if you don't want the warning, then don't use --enable-compile-warnings with ./autogen.sh or ./configure).
Can we workaround it by adding
dontwarn="$dontwarn -Wabi" dontwarn="$dontwarn -Wdeprecated"
to our m4 config, until such time as we rebase gnulib ?
Sure. Done as follows, under the trivial rule: From f17e0e2182ecefd9ba9eb346bab839cd5b59fb9c Mon Sep 17 00:00:00 2001 From: Eric Blake <eblake@redhat.com> Date: Mon, 5 Dec 2011 10:14:55 -0700 Subject: [PATCH] build: reduce warnings from older gcc Older gcc warns (on every file!) that -Wabi and -Wdeprecated only make sense on C++ projects. Newer gcc accepts these warnings for C, but it is not clear that they can do anything useful, so it is easier to just drop the warnings altogether. * m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Silence -Wabi and -Wdeprecated on older gcc. Reported by Peter Krempa. --- m4/virt-compile-warnings.m4 | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/m4/virt-compile-warnings.m4 b/m4/virt-compile-warnings.m4 index a17e4b7..ba388aa 100644 --- a/m4/virt-compile-warnings.m4 +++ b/m4/virt-compile-warnings.m4 @@ -22,6 +22,8 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[ # Don't care about C++ compiler compat dontwarn="$dontwarn -Wc++-compat" + dontwarn="$dontwarn -Wabi" + dontwarn="$dontwarn -Wdeprecated" # Don't care about ancient C standard compat dontwarn="$dontwarn -Wtraditional" # Don't care about ancient C standard compat -- 1.7.7.3 -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Sun, Dec 04, 2011 at 04:10:34PM +0800, Daniel Veillard wrote:
On Fri, Dec 02, 2011 at 02:30:35PM +0100, Peter Krempa wrote:
On 12/02/2011 01:42 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
But that means we really are committing to an rc2.
Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-)
Daniel
The problem was caused by two threads that both were thinking they are having the buck and entering poll() which caused some clients to hang. It was possible due to a race condition and therefore was not 100% reproducible. It should be fixed now with: http://www.redhat.com/archives/libvir-list/2011-December/msg00116.html
Indeed, the current git head works fine again for me, thanks a lot for chasing this :-)
So I made an second release candidate available at:
ftp://libvirt.org/libvirt/libvirt-0.9.8-rc2.tar.gz
along with rpms, I also tagged git with it. Hopefully the builds on BSD and Windows should be fixed, it would be good if it could be tested on OsX and since there was a build done last month on Android, I wonder if this could be done again [1].
The rc2 build now also looks good on Debian's kFreeBSD buildds thanks to the fixes that went in since rc1: https://buildd.debian.org/status/package.php?p=libvirt&suite=experimental Cheers, -- Guido
On Sun, Dec 04, 2011 at 04:10:34PM +0800, Daniel Veillard wrote:
On Fri, Dec 02, 2011 at 02:30:35PM +0100, Peter Krempa wrote:
On 12/02/2011 01:42 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
But that means we really are committing to an rc2.
Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-)
Daniel
The problem was caused by two threads that both were thinking they are having the buck and entering poll() which caused some clients to hang. It was possible due to a race condition and therefore was not 100% reproducible. It should be fixed now with: http://www.redhat.com/archives/libvir-list/2011-December/msg00116.html
Indeed, the current git head works fine again for me, thanks a lot for chasing this :-)
So I made an second release candidate available at:
ftp://libvirt.org/libvirt/libvirt-0.9.8-rc2.tar.gz
along with rpms, I also tagged git with it. Hopefully the builds on BSD and Windows should be fixed, it would be good if it could be tested on OsX and since there was a build done last month on Android, I wonder if this could be done again [1].
Thre is something very broken in the RPC code when an event loop is activated, which is resulting in frequent crashes. Fixing this is a release blocker IMHO. Attaching a demo program which crashes 50% of the time or more with GIT head. 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 12/07/2011 01:12 PM, Daniel P. Berrange wrote:
On Sun, Dec 04, 2011 at 04:10:34PM +0800, Daniel Veillard wrote:
On Fri, Dec 02, 2011 at 02:30:35PM +0100, Peter Krempa wrote:
On 12/02/2011 01:42 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
But that means we really are committing to an rc2. Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-)
Daniel
The problem was caused by two threads that both were thinking they are having the buck and entering poll() which caused some clients to hang. It was possible due to a race condition and therefore was not 100% reproducible. It should be fixed now with: http://www.redhat.com/archives/libvir-list/2011-December/msg00116.html Indeed, the current git head works fine again for me, thanks a lot for chasing this :-)
So I made an second release candidate available at:
ftp://libvirt.org/libvirt/libvirt-0.9.8-rc2.tar.gz
along with rpms, I also tagged git with it. Hopefully the builds on BSD and Windows should be fixed, it would be good if it could be tested on OsX and since there was a build done last month on Android, I wonder if this could be done again [1]. Thre is something very broken in the RPC code when an event loop is activated, which is resulting in frequent crashes. Fixing this is a release blocker IMHO.
Attaching a demo program which crashes 50% of the time or more with GIT head.
Daniel
Daniel, I've been trying it myself using the syntax like: gcc -Wall -o libvirt-test `pkg-config --libs --cflags libvirt` -lpthread libvirt-test.c to run it both as root and non-root and also with a guest running and not-running and it never failed for me on my Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz i686 system with 4 GB of RAM (just 2.9 GB really available because of 32-bit system). I was thinking of adding this into the tests directory and putting it directly to the tests run by `make check`. What do you think about this? Michal -- Michal Novotny <minovotn@redhat.com>, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org
On Wed, Dec 07, 2011 at 01:25:10PM +0100, Michal Novotny wrote:
On 12/07/2011 01:12 PM, Daniel P. Berrange wrote:
On Sun, Dec 04, 2011 at 04:10:34PM +0800, Daniel Veillard wrote:
On Fri, Dec 02, 2011 at 02:30:35PM +0100, Peter Krempa wrote:
On 12/02/2011 01:42 AM, Daniel Veillard wrote:
On Thu, Dec 01, 2011 at 02:11:24PM -0700, Eric Blake wrote:
But that means we really are committing to an rc2. Definitely. For example there is apparently a problem with commit fa9595003d043df9f2efe95521c00898cef27106 that we ough to fix quickly too to allow further testing :-)
Daniel
The problem was caused by two threads that both were thinking they are having the buck and entering poll() which caused some clients to hang. It was possible due to a race condition and therefore was not 100% reproducible. It should be fixed now with: http://www.redhat.com/archives/libvir-list/2011-December/msg00116.html Indeed, the current git head works fine again for me, thanks a lot for chasing this :-)
So I made an second release candidate available at:
ftp://libvirt.org/libvirt/libvirt-0.9.8-rc2.tar.gz
along with rpms, I also tagged git with it. Hopefully the builds on BSD and Windows should be fixed, it would be good if it could be tested on OsX and since there was a build done last month on Android, I wonder if this could be done again [1]. Thre is something very broken in the RPC code when an event loop is activated, which is resulting in frequent crashes. Fixing this is a release blocker IMHO.
Attaching a demo program which crashes 50% of the time or more with GIT head.
Daniel
Daniel, I've been trying it myself using the syntax like:
gcc -Wall -o libvirt-test `pkg-config --libs --cflags libvirt` -lpthread libvirt-test.c
to run it both as root and non-root and also with a guest running and not-running and it never failed for me on my Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz i686 system with 4 GB of RAM (just 2.9 GB really available because of 32-bit system).
I was thinking of adding this into the tests directory and putting it directly to the tests run by `make check`. What do you think about this?
This demo program isn't really suitable for running as a unit test, since it depends on a suitably running libvirt. It would be possible to write a unit test though, that directly uses the virNetClient and virNetServer APIs. 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 11/30/2011 10:48 PM, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.8 . For portability sake I think adding more support for PPC machines should still be allowed for a few days, as long as it's not impacting too much of the common code.
I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.8-rc1.tar.gz and the git tree is tagged.
I think I will make an rc2 on Mon or Thu and then try to make the release around Thursday next week if things looks good.
Please give it a try !
thanks in advance,
Commit ea7182c2 broke builds on RHEL5, where libxml2 2.6.26 did not yet export xmlChildElementCount. I'll post a patch shortly, once I figure out the right workaround. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (7)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Guido Günther -
Jason Helfman -
Michal Novotny -
Peter Krempa