[libvirt] F10 rpm problems
So...I decided to make the leap, and upgraded to F10 (from F9) After my upgrade, I decided to build the libvirt rpm from source, and install it. So far, so good...everything built, and installs nicely. However, when I run virsh, I get the following error: virsh: error while loading shared libraries: libgnutls.so.13: cannot open shared object file: No such file or directory Fedora 10 has /usr/lib/libgnutls.so.26, so I'm not real sure why it is looking for the old F9 versions. I have tried a make clean, make distclean, even re-cloning the repo...without effect. Does anyone have any thoughts as to why it is choosing this version of gnutls?
On Fri, Dec 05, 2008 at 03:24:31PM -0500, Ben Guthro wrote:
So...I decided to make the leap, and upgraded to F10 (from F9)
After my upgrade, I decided to build the libvirt rpm from source, and install it. So far, so good...everything built, and installs nicely.
However, when I run virsh, I get the following error: virsh: error while loading shared libraries: libgnutls.so.13: cannot open shared object file: No such file or directory
Fedora 10 has /usr/lib/libgnutls.so.26, so I'm not real sure why it is looking for the old F9 versions.
I have tried a make clean, make distclean, even re-cloning the repo...without effect.
Does anyone have any thoughts as to why it is choosing this version of gnutls?
You don't have an one laying around in /usr/local which would be picked up by the linker, but not caught by ldconfig ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
I do have older versions (for chroot purposes) mounted in non-standard paths... I don't know why it would pick it up in /data: $ locate libgnutls.so.13 /data/f9root/usr/lib64/libgnutls.so.13 /data/f9root/usr/lib64/libgnutls.so.13.9.1 The strange part is, that it looks like it is linking against both versions: $ ldd .libs/virsh linux-vdso.so.1 => (0x00007fff633ff000) libvirt.so.0 => /usr/lib/libvirt.so.0 (0x000000382da00000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003cf2a00000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003ce9200000) libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x0000003cff600000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003cf9600000) libxenstore.so.3.0 => /usr/lib64/libxenstore.so.3.0 (0x0000000000110000) libreadline.so.5 => /lib64/libreadline.so.5 (0x0000003ce7200000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ce8a00000) libc.so.6 => /lib64/libc.so.6 (0x0000003ce7e00000) libgnutls.so.13 => not found libhal.so.1 => /usr/lib64/libhal.so.1 (0x0000003cf6000000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x000000000061e000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003ce8600000) libz.so.1 => /lib64/libz.so.1 (0x0000003ce8e00000) libm.so.6 => /lib64/libm.so.6 (0x0000003ce8200000) /lib64/ld-linux-x86-64.so.2 (0x0000003ce6a00000) libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x0000003cfee00000) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x0000003cfb600000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x0000003cf8e00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003cefa00000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003cf7c00000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003cf6c00000) libcap.so.2 => /lib64/libcap.so.2 (0x0000003ce6e00000) I take it that this situation is unique to my setup, and not F10? -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com] Sent: Mon 12/8/2008 5:39 AM To: Ben Guthro Cc: libvir-list Subject: Re: [libvirt] F10 rpm problems On Fri, Dec 05, 2008 at 03:24:31PM -0500, Ben Guthro wrote:
So...I decided to make the leap, and upgraded to F10 (from F9)
After my upgrade, I decided to build the libvirt rpm from source, and install it. So far, so good...everything built, and installs nicely.
However, when I run virsh, I get the following error: virsh: error while loading shared libraries: libgnutls.so.13: cannot open shared object file: No such file or directory
Fedora 10 has /usr/lib/libgnutls.so.26, so I'm not real sure why it is looking for the old F9 versions.
I have tried a make clean, make distclean, even re-cloning the repo...without effect.
Does anyone have any thoughts as to why it is choosing this version of gnutls?
You don't have an one laying around in /usr/local which would be picked up by the linker, but not caught by ldconfig ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Dec 08, 2008 at 07:53:10AM -0500, Ben Guthro wrote:
I do have older versions (for chroot purposes) mounted in non-standard paths... I don't know why it would pick it up in /data:
$ locate libgnutls.so.13 /data/f9root/usr/lib64/libgnutls.so.13 /data/f9root/usr/lib64/libgnutls.so.13.9.1
The strange part is, that it looks like it is linking against both versions:
What I suspect is going on here then, is that you have some environment variable set causing libvirt to detect & use the version in /data/f9root. Perhaps PKG_CONFIG_PATH or a LD_LIBRARY_PATH or CFLAGS/LDFLAGS - check the config.log file and output from running configure. This would cause libvirt to directly link to libgnutls.so.13. Then, some other library in the system we're using has already linked to gnutls.so.26 and so you get the second indirect linkage. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
FYI - in case anyone else runs into this... I must have done a 'make install' somewhere in the past that installed into /usr/lib instead of /usr/lib64 (where the rpm installs it) This libvirt version was linked against the missing libgnutls.so.13, and this was what was getting picked up by virsh. Daniel P. Berrange wrote on 12/08/2008 08:00 AM:
On Mon, Dec 08, 2008 at 07:53:10AM -0500, Ben Guthro wrote:
I do have older versions (for chroot purposes) mounted in non-standard paths... I don't know why it would pick it up in /data:
$ locate libgnutls.so.13 /data/f9root/usr/lib64/libgnutls.so.13 /data/f9root/usr/lib64/libgnutls.so.13.9.1
The strange part is, that it looks like it is linking against both versions:
What I suspect is going on here then, is that you have some environment variable set causing libvirt to detect & use the version in /data/f9root. Perhaps PKG_CONFIG_PATH or a LD_LIBRARY_PATH or CFLAGS/LDFLAGS - check the config.log file and output from running configure. This would cause libvirt to directly link to libgnutls.so.13. Then, some other library in the system we're using has already linked to gnutls.so.26 and so you get the second indirect linkage.
Daniel
Hello, I have kicked around an idea before with some of you about iptables...basically being able to have iptables rules that are associated with the metadata around a particular vm, then apply those to the host iptables when the vm is spun up or migrated to that host. I emailed with James he thinks the pieces are there but integration work is needed (as well as the central management). Would someone be willing to help me understand what major pieces of work would be needed to make this possible? Regards, Karl
On Tue, 2008-12-09 at 17:30 -0500, Karl Wirth wrote:
Hello,
I have kicked around an idea before with some of you about iptables...basically being able to have iptables rules that are associated with the metadata around a particular vm, then apply those to the host iptables when the vm is spun up or migrated to that host.
Especially the interesting issues around taking the nf/ip_conntrack data and making sure that state information is correctly migrated.
I emailed with James he thinks the pieces are there but integration work is needed (as well as the central management). Would someone be willing to help me understand what major pieces of work would be needed to make this possible?
Regards, Karl
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (5)
-
Andrew Cathrow -
Ben Guthro -
Daniel P. Berrange -
Daniel Veillard -
Karl Wirth