vagrant 2.0.0 on openSuse Leap 42.2 won't build vagrant-libvirt

[hemna]

Please note that the Vagrant issue tracker is reserved for bug reports and
enhancements. For general usage questions, please use the Vagrant mailing list:
https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Vagrant version

I installed the RPM from https://releases.hashicorp.com/vagrant/2.0.0/vagrant_2.0.0_x86_64.rpm
stack@linux-3n06:~> vagrant --version
Vagrant 2.0.0

Host operating system

stack@linux-3n06:~> cat /etc/issue
Welcome to openSUSE Leap 42.2 - Kernel \r (\l).

Expected behavior

vagrant plugin install vagrant-libvirt should build.

Actual behavior

stack@linux-3n06:~> vagrant plugin install vagrant-libvirt
Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
Fetching: vagrant-share-1.1.9.gem (100%)
Fetching: excon-0.59.0.gem (100%)
Fetching: formatador-0.2.5.gem (100%)
Fetching: fog-core-1.43.0.gem (100%)
Fetching: fog-json-1.0.2.gem (100%)
Fetching: mini_portile2-2.1.0.gem (100%)
Fetching: nokogiri-1.6.8.1.gem (100%)
Building native extensions. This could take a while...
Fetching: fog-xml-0.1.3.gem (100%)
Fetching: ruby-libvirt-0.7.0.gem (100%)
Building native extensions. This could take a while...
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:

ERROR: Failed to build gem native extension.

current directory: /home/stack/.vagrant.d/gems/2.3.4/gems/ruby-libvirt-0.7.0/ext/libvirt

/opt/vagrant/embedded/bin/ruby -r ./siteconf20170920-5628-1yrff14.rb 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_BASE_NAME)
--with-libvirt-include
--without-libvirt-include
--with-libvirt-lib
--without-libvirt-lib
--with-libvirt-config
--without-libvirt-config
--with-pkg-config
--without-pkg-config
extconf.rb:73:in `

': libvirt library not found in default locations (RuntimeError)

To see why this extension failed to compile, please check the mkmf.log which can be found here:

/home/stack/.vagrant.d/gems/2.3.4/extensions/x86_64-linux/2.3.0/ruby-libvirt-0.7.0/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /home/stack/.vagrant.d/gems/2.3.4/gems/ruby-libvirt-0.7.0 for inspection.
Results logged to /home/stack/.vagrant.d/gems/2.3.4/extensions/x86_64-linux/2.3.0/ruby-libvirt-0.7.0/gem_make.out

stack@linux-3n06:~> cat /home/stack/.vagrant.d/gems/2.3.4/extensions/x86_64-linux/2.3.0/ruby-libvirt-0.7.0/mkmf.log
"pkg-config --exists libvirt"
| pkg-config --libs libvirt
=> "-lvirt \n"
"gcc -o conftest -I/opt/vagrant/embedded/include/ruby-2.3.0/x86_64-linux -I/opt/vagrant/embedded/include/ruby-2.3.0/ruby/backward -I/opt/vagrant/embedded/include/ruby-2.3.0 -I. -I/opt/vagrant/embedded/include -I/opt/vagrant/embedded/include -I/vagrant-substrate/cache/ruby-2.3.4/include -fPIC conftest.c -L. -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -L. -L/opt/vagrant/embedded/lib -Wl,-rpath=XORIGIN/../lib:/opt/vagrant/embedded/lib -fstack-protector -rdynamic -Wl,-export-dynamic -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -Wl,-rpath,'/../lib' -Wl,-R'/../lib' -lruby -lpthread -lrt -ldl -lcrypt -lm -lc"
sh: /opt/vagrant/embedded/lib/libreadline.so.6: no version information available (required by sh)
checked program was:
/* begin /
1: #include "ruby.h"
2:
3: int main(int argc, char *argv)
4: {
5: return 0;
6: }
/* end */

"gcc -o conftest -I/opt/vagrant/embedded/include/ruby-2.3.0/x86_64-linux -I/opt/vagrant/embedded/include/ruby-2.3.0/ruby/backward -I/opt/vagrant/embedded/include/ruby-2.3.0 -I. -I/opt/vagrant/embedded/include -I/opt/vagrant/embedded/include -I/vagrant-substrate/cache/ruby-2.3.4/include -fPIC conftest.c -L. -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -L. -L/opt/vagrant/embedded/lib -Wl,-rpath=XORIGIN/../lib:/opt/vagrant/embedded/lib -fstack-protector -rdynamic -Wl,-export-dynamic -L/opt/vagrant/embedded/lib -Wl,-R/opt/vagrant/embedded/lib -Wl,-rpath,'/../lib' -Wl,-R'/../lib' -lruby -lvirt -lpthread -lrt -ldl -lcrypt -lm -lc"
sh: /opt/vagrant/embedded/lib/libreadline.so.6: no version information available (required by sh)
checked program was:
/* begin /
1: #include "ruby.h"
2:
3: int main(int argc, char *argv)
4: {
5: return 0;
6: }
/* end */

package configuration for libvirt is not found

Steps to reproduce

1. install vagrant 2.0.0 from rpm
   sudo zypper in vagrant_2.0.0_x86_64.rpm
2. sudo zypper in libvirt libvirt-devel gcc kvm qemu
3. vagrant plugin install vagrant-libvirt

[aspiers]

I encountered exactly the same problem with Vagrant 1.9.8, and have verified that it is definitely caused by the warning seen in mkmf.log:

sh: /opt/vagrant/embedded/lib/libreadline.so.6: no version information available (required by sh)

This is because since 1.9.3, Ruby's mkmf.rb checks that the output of the compilation of the simple conftest.c file is empty, and if it's non-empty, it treats it as equivalent to a compilation failure:

https://github.com/ruby/ruby/commit/e806b0fed77d94ea426bfc0269ab3b01feaf218c#diff-7aa560cb6196deeb96779cd175e8e589R308

Since the build process will fall back to using normal system-wide libraries if they are not found inside /opt/vagrant/embedded, I have found that this issue can be worked around simply by ensuring that the openSUSE version of that library is installed (the libreadline6 package) and then doing:

mv /opt/vagrant/embedded/lib/libreadline.so.6{,.disabled}

However, it seems to me that there are two things which ideally should be fixed:

1. Fix whatever mechanism builds the Vagrant rpm, so that embedded libraries do not have this problem. I'm not yet sure whether the problem is missing ELF version information as the warning suggests, or simply a version mismatch - this StackOverflow question seems to have contradictory answers.
2. Improve Ruby's mkmf.rb so that if the gcc build succeeds (exit status 0) but generates some output, it is much clearer about why it is failing. Currently it gives the impression that the compile is failing, which is very misleading.

[aspiers]

An interesting further observation, which suggests that Hashicorp's method of building /opt/vagrant/embedded/lib/libreadline.so.6 is suspect:

$ readelf -V /lib64/libreadline.so.6 | grep READLINE
  08c:   1 (*global*)      1 (*global*)      2 (READLINE_6.3)   1 (*global*)
  0f4:   1 (*global*)      1 (*global*)      2 (READLINE_6.3)   1 (*global*)
  140:   2 (READLINE_6.3)   1 (*global*)      1 (*global*)      1 (*global*)
  198:   1 (*global*)      2 (READLINE_6.3)   1 (*global*)      1 (*global*)
  1a4:   1 (*global*)      1 (*global*)      2 (READLINE_6.3)   1 (*global*)
  1fc:   2 (READLINE_6.3)   1 (*global*)      1 (*global*)      1 (*global*)
  20c:   2 (READLINE_6.3)   1 (*global*)      2 (READLINE_6.3)   1 (*global*)
  284:   1 (*global*)      2 (READLINE_6.3)   1 (*global*)      1 (*global*)
  28c:   1 (*global*)      1 (*global*)      1 (*global*)      2 (READLINE_6.3)
  298:   1 (*global*)      2 (READLINE_6.3)   1 (*global*)      1 (*global*)
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: READLINE_6.3
$ readelf -V /opt/vagrant/embedded/lib/libreadline.so.6 | grep READLINE | wc -l
0

So it seems that the version information really is missing, despite what this popularly voted answer suggests.

The odd thing is that even though I could reproduce this on another environment, I couldn't on my personal laptop which also running openSUSE Leap 42.2. So there must be some other factor contributing to the output of this message.

[briancain]

Hi @hemna and @aspiers, there have been some updates to the Vagrant packaging that I believe should fix your problem. I recently installed vagrant_2.0.2_x86_64.rpm on openSUSE Leap 42.3 - Kernel \r (\l). and I was able to successfully install the vagrant-libvirt plugin. Please try 2.0.2 and let me know if that solves the problem. Thanks!

[aspiers]

Thanks a lot @briancain for the update! I'm very busy at the moment so can't guarantee I'll be able to look at this soon, but I'll definitely take a look the next time I'm working in this area!

[briancain]

Sounds good @aspiers ! I'm going to go ahead and close this issue, but if you find that it's still broke, please feel free to re-open it or open a new issue. Thanks!

[hemna]

@briancain thanks, I just installed 2.0.2 on Leap 42.3 and it worked :)

[denisok]

I have same issue on Tumbleweed. Tried 2.0.3 and 2.1.1 .

readelf -V /opt/vagrant/embedded/lib/libreadline.so.7 | grep READLINE | wc -l
0

Fails for gems/2.4.3/extensions/x86_64-linux/2.4.0/nokogiri-1.8.2 .

Removing embedded lib as @aspiers suggested - works fine.

2.0.3 works fine on 42.3.

[denisok]

could we reopen this? @mogeb also see this issue for openSUSE 15

[briancain]

@denisok - please open a new issue and fill out the issue template if you're running into a problem with the latest version of Vagrant. Thanks!

[rtamalin]

For reference @briancain this problem is happening again for openSUSE Leap 15, which defaults to installing libreadline7 as the system version of libreadline.

I have successfully reproduced the issue for the Vagrant 2.1.2 and 2.0.4 RPMs when testing them on a newly installed openSUSE Leap 15 system.

The workaround of renaming the embedded version of libreadline.so.7 with a .disabled extension gets past the issue and allows the successful building of the vagrant-libvirt plugin.

[hashibot[bot]]

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.