[libvirt] libprl_sdk.so.7 library dependancies

[Daniel P. Berrange]

In debugging some recent problem I was rather surprised to find that
libvirt.so was linked against Qt, X11 and GObject.  It turns out that
this is due to the VZ driver linking to libprl_sdk.so which pulls in
all these libs:

 $ ldd /usr/lib64/libprl_sdk.so.7.0.26 
	linux-vdso.so.1 (0x00007fff443d3000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f4f8f415000)
	libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f4f8f210000)
	librt.so.1 => /usr/lib64/librt.so.1 (0x00007f4f8f008000)
	libQtXml.so.4 => /usr/lib64/libQtXml.so.4 (0x00007f4f8edc1000)
	libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x00007f4f8e087000)
	libQtNetwork.so.4 => /usr/lib64/libQtNetwork.so.4 (0x00007f4f8dd33000)
	libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x00007f4f8d82c000)
	libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f4f8d60e000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f4f8d3fc000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f4f8d0bc000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4f8cd39000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007f4f8ca37000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f4f8c820000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f4f8c45e000)
	/lib64/ld-linux-x86-64.so.2 (0x000055817de34000)
	libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f4f8c25c000)
	libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f4f8bf23000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f4f8bcef000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f4f8ba45000)
	libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f4f8b7f3000)
	libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f4f8b5e9000)
	libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f4f8b3cd000)
	libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f4f8b1bd000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f4f8afb1000)
	libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f4f8ada6000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f4f8aba0000)
	libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f4f8a994000)
	libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f4f8a791000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f4f8a54d000)
	libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f4f8a2d3000)
	libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f4f89e86000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f4f89c63000)
	libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f4f89a53000)
	libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f4f8984a000)
	libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f4f89645000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f4f8941a000)
	libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f4f891cc000)
	libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f4f88ee7000)
	libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007f4f88ce2000)
	libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f4f88ab0000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f4f888ac000)
	libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f4f8869c000)
	libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007f4f88498000)
	libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007f4f8827d000)
	libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007f4f88059000)
	libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f4f87de9000)


This is bad for several reasons - libvirt should not pull in any GUI libraries
at all, since virt hosts typically want to avoid any deps on this kind of
packages in order to get a minimal hypervisor node install. Second, with
libgobject in particular, this library abort()s when it hits out of memory
conditions. This is absolutely against the policy of libvirt.so which is
that we must feed all errors back to the caller and *never* abort a program
using libvirt.so

Since it is not in Fedora, I'm using libprlsdk.so from an RPM I built
myself -  libprlsdk-7.0.26-1.fc22.x86_64.  So possibly this is just a
mistake in the way I built the library ?  If this long list of deps
is normal / expected though, then we have a much bigger problem that
I don't think we can solve in libvirt.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|