Problem in installing vagrant-libvirt and vagrant-kvm
opened this issue · comments
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-kvmbefore 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.
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:
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?
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).
@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.
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.
what are the issues with ld.gold ?
imho it should be the standard linker unless you want to produce a.out binaries.
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.
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)
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.