[libvirt] [PATCH] Implement virVMOperationType{To|From}String independent from WITH_MACVTAP
As this symbols are exported independent from WITH_MACVTAP. --- src/util/macvtap.c | 33 +++++++++++++++++++-------------- 1 files changed, 19 insertions(+), 14 deletions(-) diff --git a/src/util/macvtap.c b/src/util/macvtap.c index 2aa319c..4345d97 100644 --- a/src/util/macvtap.c +++ b/src/util/macvtap.c @@ -27,12 +27,13 @@ #include <config.h> +#include <stdint.h> + #if WITH_MACVTAP || WITH_VIRTUALPORT # include <stdio.h> # include <errno.h> # include <fcntl.h> -# include <stdint.h> # include <c-ctype.h> # include <sys/socket.h> # include <sys/ioctl.h> @@ -44,10 +45,15 @@ # include <netlink/msg.h> -# include "util.h" +#endif /* WITH_MACVTAP || WITH_VIRTUALPORT */ + +#include "util.h" +#include "macvtap.h" + +#if WITH_MACVTAP || WITH_VIRTUALPORT + # include "memory.h" # include "logging.h" -# include "macvtap.h" # include "interface.h" # include "conf/domain_conf.h" # include "virterror_internal.h" @@ -77,17 +83,6 @@ # define LLDPAD_PID_FILE "/var/run/lldpad.pid" -VIR_ENUM_IMPL(virVMOperation, VIR_VM_OP_LAST, - "create", - "save", - "restore", - "destroy", - "migrate out", - "migrate in start", - "migrate in finish", - "no-op") - - enum virVirtualPortOp { ASSOCIATE = 0x1, DISASSOCIATE = 0x2, @@ -1609,3 +1604,13 @@ vpDisassociatePortProfileId(const char *macvtap_ifname, } #endif /* WITH_MACVTAP || WITH_VIRTUALPORT */ + +VIR_ENUM_IMPL(virVMOperation, VIR_VM_OP_LAST, + "create", + "save", + "restore", + "destroy", + "migrate out", + "migrate in start", + "migrate in finish", + "no-op") -- 1.7.0.4
On 12/03/2010 10:43 AM, Matthias Bolte wrote:
As this symbols are exported independent from WITH_MACVTAP. --- src/util/macvtap.c | 33 +++++++++++++++++++-------------- 1 files changed, 19 insertions(+), 14 deletions(-)
ACK. Hmm, maybe we should patch ./autobuild.sh to intentionally try a stripped-down build with as many features disabled as possible to help catch some of these cases where a full-featured build passes but a reduced build fails. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
2010/12/3 Eric Blake <eblake@redhat.com>:
On 12/03/2010 10:43 AM, Matthias Bolte wrote:
As this symbols are exported independent from WITH_MACVTAP. --- src/util/macvtap.c | 33 +++++++++++++++++++-------------- 1 files changed, 19 insertions(+), 14 deletions(-)
ACK.
Thanks, pushed.
Hmm, maybe we should patch ./autobuild.sh to intentionally try a stripped-down build with as many features disabled as possible to help catch some of these cases where a full-featured build passes but a reduced build fails.
Well, that would not have helped to detect this. The problem here is that we allow undefined symbols to be exported on Linux but use the libtool -no-undefined option on Windows because exporting undefined symbols doesn't work on Windows. We should probably just use -no-undefined on all platforms, or do I miss the reason why we need this feature of exporting undefined symbols on Linux? Matthias
On 12/04/2010 11:37 AM, Matthias Bolte wrote:
Well, that would not have helped to detect this. The problem here is that we allow undefined symbols to be exported on Linux but use the libtool -no-undefined option on Windows because exporting undefined symbols doesn't work on Windows. We should probably just use -no-undefined on all platforms, or do I miss the reason why we need this feature of exporting undefined symbols on Linux?
I see no reason why we should avoid -no-undefined on Linux. Given that our libraries should already be completely resolved for the sake of Windows, using -no-undefined on Linux might serve to help catch bugs that would affect Windows, and should not have any impact in the normal case of correct exports. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Sat, Dec 04, 2010 at 01:32:16PM -0700, Eric Blake wrote:
On 12/04/2010 11:37 AM, Matthias Bolte wrote:
Well, that would not have helped to detect this. The problem here is that we allow undefined symbols to be exported on Linux but use the libtool -no-undefined option on Windows because exporting undefined symbols doesn't work on Windows. We should probably just use -no-undefined on all platforms, or do I miss the reason why we need this feature of exporting undefined symbols on Linux?
I see no reason why we should avoid -no-undefined on Linux. Given that our libraries should already be completely resolved for the sake of Windows, using -no-undefined on Linux might serve to help catch bugs that would affect Windows, and should not have any impact in the normal case of correct exports.
Yep, we should use it everywhere, except that note there is some platform oddity. Win32 platforms must always use -no-undefined while Solaris must always use -Wl,--no-undefined. Linux can use either. So in GTK-VNC I use the former on Win32, and the latter everywhere else. Daniel
On 12/06/2010 04:21 AM, Daniel P. Berrange wrote:
On Sat, Dec 04, 2010 at 01:32:16PM -0700, Eric Blake wrote:
On 12/04/2010 11:37 AM, Matthias Bolte wrote:
Well, that would not have helped to detect this. The problem here is that we allow undefined symbols to be exported on Linux but use the libtool -no-undefined option on Windows because exporting undefined symbols doesn't work on Windows. We should probably just use -no-undefined on all platforms, or do I miss the reason why we need this feature of exporting undefined symbols on Linux?
I see no reason why we should avoid -no-undefined on Linux. Given that our libraries should already be completely resolved for the sake of Windows, using -no-undefined on Linux might serve to help catch bugs that would affect Windows, and should not have any impact in the normal case of correct exports.
Yep, we should use it everywhere, except that note there is some platform oddity. Win32 platforms must always use -no-undefined while Solaris must always use -Wl,--no-undefined. Linux can use either. So in GTK-VNC I use the former on Win32, and the latter everywhere else.
Huh? -Wl,--no-undefined is a compiler option specific to some compilers, while -no-undefined is a libtool option that libtool should automatically be rewriting as the underlying command understood by the compiler detected by libtool. That is, if 'libtool -no-undefined' doesn't get rewritten under the hood to use -Wl,--no-undefined on Solaris, then that's a libtool bug which should be reported upstream. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Matthias Bolte