[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]