[libvirt] PATCH: 7/11: Build libtool convenience libraries of all drivers

Daniel Veillard veillard at redhat.com
Thu Oct 30 14:49:50 UTC 2008


On Thu, Oct 30, 2008 at 01:39:33PM +0000, Daniel P. Berrange wrote:
> A while ago we introduced a libvirt_test.so which is identical to
> libvirt.so, but without the linker whitelist of symbols. This did
> impose a little overhead in the build process - it meant we compiled
> all source files twice.
> 
> A future patch will want to compile drivers into individual libraries
> to allow dlopening, and it occurred to me that if we built some more
> libtool convenience libraries we could avoid the double compilation.
> 
> The trick is that libvirt.la must not have any source files listed
> against it. It must only be used to link together other convenience
> libraries. So, I define a while set of libraries
> 
>  - libvirt_util.la - generic code not related to drivers or libvirt API
>  - libvirt_driver.la - the libvirt public API and driver support code
>  - libvirt_driver_XXXX.la - one for each of qemu, xen, test, remote,
>                             openvz, lxc, storage, network
> 
> These are all convenience libraries, so libtool will just build a local
> non-installed, static .a archive.
> 
> Now, the actual things we care about
> 
>  - libvirt.la - links to all of these convenience .la libraries together
>                 and adds the libvirt_sym.version script to filter symbols
>  - libvirt_test.la - the same, but with the version script
>  - libvirt_lxc - links to libvirt_util.la and libvirt_driver_lxc.la
>  - virsh - links to libvirt.la
> 
> So the end result is that each source file is only ever compiled once,
> and each library/program just links to the .a files is actually needs.

  In principle it's fine, it's equivalent, but it's a bit complex.
Maybe this description should go somewhere in the HACKING file too
i assume we can still compile with --disable-shared and everything will
just build and link fine, just that the .la will be replaced with
good old .a and the binaries will have them statically linked in.
  I we can just double check this, +1

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list