26.11.2015 20:08, Maxim Nestratov пишет:
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
26.11.2015 18:19, Daniel P. Berrange пишет: 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. Daniel,
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 Best, Maxim