hashicorp/vagrant

Problem in installing vagrant-libvirt and vagrant-kvm

Opened this issue · 9 comments

Deleted user commented

As I wrote in vagrant-libvirt/vagrant-libvirt#290 ...

I tried to install vagrant-libvirt on a fresh Fedora 21 Installation.

➜  ~  vagrant version
Installed Version: 1.7.1
Latest Version: 1.7.1

You're running an up-to-date version of Vagrant!

I did a:

➜  ~  vagrant plugin install vagrant-libvirt 
Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

An error occurred while installing ruby-libvirt (0.5.2), and Bundler cannot continue.
Make sure that `gem install ruby-libvirt -v '0.5.2'` succeeds before bundling.

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

    /opt/vagrant/embedded/bin/ruby extconf.rb 
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
    --with-opt-dir
    --with-opt-include
    --without-opt-include=${opt-dir}/include
    --with-opt-lib
    --without-opt-lib=${opt-dir}/lib
    --with-make-prog
    --without-make-prog
    --srcdir=.
    --curdir
    --ruby=/opt/vagrant/embedded/bin/ruby
    --with-libvirt-include
    --without-libvirt-include
    --with-libvirt-lib
    --without-libvirt-lib
    --with-libvirt-config
    --without-libvirt-config
    --with-pkg-config
    --without-pkg-config
/opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:434:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
    from /opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:519:in `try_link0'
    from /opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:534:in `try_link'
    from /opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:620:in `block in try_ldflags'
    from /opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:613:in `with_ldflags'
    from /opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:619:in `try_ldflags'
    from /opt/vagrant/embedded/lib/ruby/2.0.0/mkmf.rb:1725:in `pkg_config'
    from extconf.rb:72:in `<main>'


Gem files will remain installed in /home/felix/.vagrant.d/gems/gems/ruby-libvirt-0.5.2 for inspection.
Results logged to /home/felix/.vagrant.d/gems/gems/ruby-libvirt-0.5.2/ext/libvirt/gem_make.out

And mkfm.log

➜  ~  cat /home/felix/.vagrant.d/gems/gems/ruby-libvirt-0.5.2/ext/libvirt/mkmf.log    
"gcc -o conftest -I/opt/vagrant/embedded/include/ruby-2.0.0/x86_64-linux -I/opt/vagrant/embedded/include/ruby-2.0.0/ruby/backward -I/opt/vagrant/embedded/include/ruby-2.0.0 -I.  -I/vagrant-substrate/staging/embedded/include   -I/vagrant-substrate/staging/embedded/include -fPIC conftest.c  -L. -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -L/vagrant-substrate/staging/embedded/lib -Wl,-R/vagrant-substrate/staging/embedded/lib -lvirt     '-Wl,-rpath,/../lib' -Wl,-R -Wl,/opt/vagrant/embedded/lib -L/opt/vagrant/embedded/lib -lruby  -lpthread -lrt -ldl -lcrypt -lm   -lc"
/lib64/libsystemd.so.0: undefined reference to `lzma_stream_decoder@XZ_5.0'
/lib64/libxml2.so.2: undefined reference to `lzma_auto_decoder@XZ_5.0'
/lib64/libxml2.so.2: undefined reference to `lzma_properties_decode@XZ_5.0'
/lib64/libsystemd.so.0: undefined reference to `lzma_end@XZ_5.0'
/lib64/libsystemd.so.0: undefined reference to `lzma_code@XZ_5.0'
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2: 
3: int main(int argc, char **argv)
4: {
5:   return 0;
6: }
/* end */

I also installed the know dependencies: libxslt-devel, libxml2-devel and libvirt-devel

Installing vagrant-kvm produces the same error.

There is a workaround:

I exchanged all liblzma.so* (in /opt/vagrant/embedded/lib/) for the ones from /usr/lib64/. After that the plugin installs just fine.

Installing vagrant-kvm before leads to the same error. Afterwards it also installs just fine.

So I guess the embedded lib versions are linked wrong. I checked this with objdump and got this as result, the .xxx is the original vagrant, the others the OS versions.

➜  ~  objdump -T /opt/vagrant/embedded/lib/liblzma.so.* |grep -e liblzma.so -e lzma_end -e lzma_code -e lzma_stream_decoder -e lzma_auto_decoder -e lzma_properties_decode
/opt/vagrant/embedded/lib/liblzma.so.0:     file format elf64-x86-64
00000000000099a0 g    DF .text  0000000000000074  Base        lzma_stream_decoder
0000000000008300 g    DF .text  0000000000000072  Base        lzma_properties_decode
0000000000002c70 g    DF .text  0000000000000207  Base        lzma_code
0000000000007780 g    DF .text  0000000000000074  Base        lzma_auto_decoder
0000000000002e80 g    DF .text  000000000000003f  Base        lzma_end
/opt/vagrant/embedded/lib/liblzma.so.0.0.0:     file format elf64-x86-64
00000000000099a0 g    DF .text  0000000000000074  Base        lzma_stream_decoder
0000000000008300 g    DF .text  0000000000000072  Base        lzma_properties_decode
0000000000002c70 g    DF .text  0000000000000207  Base        lzma_code
0000000000007780 g    DF .text  0000000000000074  Base        lzma_auto_decoder
0000000000002e80 g    DF .text  000000000000003f  Base        lzma_end
/opt/vagrant/embedded/lib/liblzma.so.5:     file format elf64-x86-64
000000000000b7e0 g    DF .text  0000000000000074  XZ_5.0      lzma_stream_decoder
000000000000a150 g    DF .text  0000000000000072  XZ_5.0      lzma_properties_decode
00000000000032e0 g    DF .text  0000000000000268  XZ_5.0      lzma_code
00000000000095d0 g    DF .text  0000000000000074  XZ_5.0      lzma_auto_decoder
0000000000003550 g    DF .text  000000000000003f  XZ_5.0      lzma_end
/opt/vagrant/embedded/lib/liblzma.so.5.0.7.xxx:     file format elf64-x86-64
000000000000cad3 g    DF .text  000000000000008a  Base        lzma_stream_decoder
000000000000aa09 g    DF .text  0000000000000096  Base        lzma_properties_decode
0000000000002c87 g    DF .text  0000000000000453  Base        lzma_code
00000000000099ab g    DF .text  000000000000008a  Base        lzma_auto_decoder
00000000000030da g    DF .text  000000000000005b  Base        lzma_end
/opt/vagrant/embedded/lib/liblzma.so.5.0.99:     file format elf64-x86-64
000000000000b7e0 g    DF .text  0000000000000074  XZ_5.0      lzma_stream_decoder
000000000000a150 g    DF .text  0000000000000072  XZ_5.0      lzma_properties_decode
00000000000032e0 g    DF .text  0000000000000268  XZ_5.0      lzma_code
00000000000095d0 g    DF .text  0000000000000074  XZ_5.0      lzma_auto_decoder
0000000000003550 g    DF .text  000000000000003f  XZ_5.0      lzma_end
/opt/vagrant/embedded/lib/liblzma.so.5.xxx:     file format elf64-x86-64
000000000000cad3 g    DF .text  000000000000008a  Base        lzma_stream_decoder
000000000000aa09 g    DF .text  0000000000000096  Base        lzma_properties_decode
0000000000002c87 g    DF .text  0000000000000453  Base        lzma_code
00000000000099ab g    DF .text  000000000000008a  Base        lzma_auto_decoder
00000000000030da g    DF .text  000000000000005b  Base        lzma_end
/opt/vagrant/embedded/lib/liblzma.so.xxx:     file format elf64-x86-64
000000000000cad3 g    DF .text  000000000000008a  Base        lzma_stream_decoder
000000000000aa09 g    DF .text  0000000000000096  Base        lzma_properties_decode
0000000000002c87 g    DF .text  0000000000000453  Base        lzma_code
00000000000099ab g    DF .text  000000000000008a  Base        lzma_auto_decoder
00000000000030da g    DF .text  000000000000005b  Base        lzma_end

and my system libs have following dynamic symbol table:

➜  ~  objdump -T /usr/lib64/libsystemd.so.0 /usr/lib64/libxml2.so.2  |grep -e lib64 -e lzma_end -e lzma_code -e lzma_stream_decoder -e lzma_auto_decoder -e lzma_properties_decode
/usr/lib64/libsystemd.so.0:     file format elf64-x86-64
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_stream_decoder
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_end
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_code
/usr/lib64/libxml2.so.2:     file format elf64-x86-64
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_code
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_auto_decoder
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_properties_decode
0000000000000000      DF *UND*  0000000000000000  XZ_5.0      lzma_end

Since I'm not a programmer I hope the dynamic symbol tables make any sense.

obnoxxx commented

I have worked on getting vagrant with libvirt (and lxc) running on fedora21.
Problem is that the installed liblzma has symbol versions and the libs like
libxml2 depend on these versions. Now the linker search paths in the
plugin install run are changed, the vagrant liblzma is used, and this has
no symbol versions....

There is a trick I found to work: use the gold linker instead of the bfd one:

alternatives --set ld /usr/bin/ld.gold

Here is the long story:

http://blog.obnox.de/vagrant-with-lxc-and-libvirt-on-fedora

obnoxxx commented

I think the lession is that it is not a good idea to ship some C-libraries in embedded.
It can't be selfcontained like the embedded ruby, which is completely changed away
from the system installed version. But for C-libraries we can't stay pure. We can always
get in trouble through dependencies
compiled object --> system lib --> shipped lib

Why are the libs like liblzma shipped at all in the first place?

akostadinov commented

FYI fedora 21 has now official vagrant and vagrant-libvirt RPMs. As far as I know vagrant-kvm project becomes abandoned (see https://github.com/adrahon/vagrant-kvm).

mitchellh commented

@obnoxxx They're shipped because we've run into the inverse issue when we used to not ship them: the system libraries can't be used by the embedded binaries. :) You can't win there.

Please use @obnoxxx's workaround. I don't see any other possible workaround here other than to get it to compile to the embedded LZMA.

doudou commented

Just two cents: having crashed into the same problem, I personally went for replacing vagrant's liblzma by a symlink to the system's liblzma. This fixed the problem, and avoided the pile of issues one can have when using ld.gold.

obnoxxx commented

what are the issues with ld.gold ?
imho it should be the standard linker unless you want to produce a.out binaries.

doudou commented

Did a bit of googling: http://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience

In any case, I prefer promoting a fix local to vagrant (the symlink) rather than a global change -- and as fundamental -- as changing the linker. If my distribution developers decided to not give me the choice of changing the linker, I personally assume that they had good reasons rather than having to find out what the hell is going on later.

vhosakot commented

I saw the error Failed to build gem native extension too on CentOS 7.3 and vagrant 1.8.7.

I resolved it after installing ruby-devel and gcc (yum -y install ruby-devel gcc)

Deleted user commented

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.