[libvirt] libprl_sdk.so.7 library dependancies

Daniel P. Berrange berrange at redhat.com
Fri Nov 27 17:46:08 UTC 2015


On Fri, Nov 27, 2015 at 07:48:10PM +0300, Maxim Nestratov wrote:
> 26.11.2015 20:08, 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

[snip]

> >>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.
> >>
> >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.
> 
> We got rid of all unnecessary dependencies and have just commited changes
> under
> 7.0.45 version.  Please try this new version and see if it is ok now. Just
> in case, source
> code is available here https://src.openvz.org/projects/OVZ/repos/libprlsdk

Ok, that looks much improved - now I only see it linking

$ ldd /lib64/libprl_sdk.so
	linux-vdso.so.1 (0x00007ffd29b63000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f011f4f3000)
	libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f011f2ee000)
	librt.so.1 => /usr/lib64/librt.so.1 (0x00007f011f0e6000)
	libQtXml.so.4 => /usr/lib64/libQtXml.so.4 (0x00007f011ee9f000)
	libQtNetwork.so.4 => /usr/lib64/libQtNetwork.so.4 (0x00007f011eb4a000)
	libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x00007f011e643000)
	libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f011e426000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f011e0a3000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007f011dda1000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f011db8a000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f011d7c8000)
	/lib64/ld-linux-x86-64.so.2 (0x000055f66d762000)
	libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f011d54f000)
	libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f011d102000)
	libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f011ceff000)
	libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f011cbc6000)
	libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f011c977000)
	libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f011c692000)
	libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007f011c48e000)
	libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f011c25b000)
	libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f011c04c000)
	libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007f011be48000)
	libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007f011bc2c000)
	libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007f011ba09000)
	libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f011b798000)

So none of the GUI stuff is there anymore which is nice.

I guess you actually use QT as part of your library ?  It has abort-on
OOM behaviour which is not so nice for libvirt given our policy in this
area. We can't very well ask you to rewrite your code, so probably
just have to document this aspect of the VZ driver.

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 :|




More information about the libvir-list mailing list