[libvirt] libprl_sdk.so.7 library dependancies

[Maxim Nestratov]

26.11.2015 18:19, 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
Indeed we have this kind of dependencies and I don't like them either. 
It's a kind of legacy
stuff we have right now. Actually I didn't realize before that we are 
linking with GUI libs.
Having looked at this problem now, I don't think this is really 
necessary to be linked
against. We'll try to get rid of such dependencies asap.
Thank you for pointing this out, Daniel.

Best,
Maxim