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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list