On 06/23/2010 01:13 PM, Daniel P. Berrange wrote:
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,
Too painful to be useful. :)
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.
Agreed.
Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list