[libvirt] [PATCH] Implement virVMOperationType{To|From}String independent from WITH_MACVTAP

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20101206/441c136b/attachment-0001.sig>