[libvirt] libprl_sdk.so.7 library dependancies

[Maxim Nestratov]

27.11.2015 20:46, Daniel P. Berrange пишет:
> 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
Yes, we use it as a part of our library by historical reasons and I'm 
afraid rewriting it is
not an option for us. But sure we can document it. Could you give a hint 
what documents
we should alter?