On Wed, Jun 23, 2010 at 01:08:40PM +0200, Paolo Bonzini wrote:
On 06/23/2010 12:50 PM, Daniel P. Berrange wrote:
>>> libvirt_driver_test_la_LDFLAGS = -module -avoid-version
>>> +libvirt_driver_test_la_LIBADD = libvirt.la ../gnulib/lib/libgnu.la
>I don't think it is right to link to libvirt.la here or with other
>driver modules.
>
>The libvirtd daemon links to libvirt.la already, and is built such
>that all exported symbols are available to modules that are dlopen()d
>Thus it should be sufficient to add symbols to libvirt_private.syms
>and not link to libvirt.la in driver modules.
I don't think that works on Windows. Windows DLLs must not have
undefined symbols. They do not get "magic" access to symbols exported
by previously loaded libraries and (as in this case) programs.
libtool can get around that limitation if you use its libltdl library,
but to be honest I don't really care very mcuh. Ee don't even build
libvirtd on windows currently, and even if we did, it isn't a show
stopper to just build libvirtd in the traditional way without using
the dlopen support.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|