Re: [libvirt] libprl_sdk.so.7 library dependancies

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.