Latest Failed install on Ubuntu 10.04LTS

[sr3d]

I tried installing Ruby 1.9.3 and Rails on my 3-year old VPS running Ubuntu 10.04LTS, and I'm using the twitter-bootstrap gem that depends on TheRubyRacer but I wasn't able to install the latest rubyracer. The system is x86_64.

root@ramon:~/temp/test# uname -a Linux ramon 3.9.3-x86_64-linode33 #1 SMP Mon May 20 10:22:57 EDT 2013 x86_64 GNU/Linux

However, if I install the 0.11.0beta8 version then the gem would be installed successfuly.

Failed installation:

root@ramon:~/temp/test# gem install therubyracer Fetching: libv8-3.16.14.3-x86_64-linux.gem (100%) Successfully installed libv8-3.16.14.3-x86_64-linux Building native extensions. This could take a while... ERROR: Error installing therubyracer: ERROR: Failed to build gem native extension.

/usr/local/bin/ruby extconf.rb

checking for main() in -lpthread... yes creating Makefile

make compiling constraints.cc compiling array.cc compiling value.cc compiling invocation.cc compiling primitive.cc compiling trycatch.cc compiling context.cc compiling exception.cc compiling template.cc compiling accessor.cc compiling object.cc compiling script.cc compiling external.cc compiling stack.cc compiling gc.cc compiling backref.cc compiling heap.cc compiling v8.cc compiling constants.cc compiling date.cc compiling function.cc compiling rr.cc compiling message.cc compiling init.cc compiling string.cc compiling handles.cc compiling signature.cc compiling locker.cc linking shared-object v8/init.so g++: /usr/local/lib/ruby/gems/1.9.1/gems/libv8-3.16.14.3-x86_64-linux/vendor/v8/out/ia32.release/obj.target/tools/gyp/libv8_base.a: No such file or directory g++: /usr/local/lib/ruby/gems/1.9.1/gems/libv8-3.16.14.3-x86_64-linux/vendor/v8/out/ia32.release/obj.target/tools/gyp/libv8_snapshot.a: No such file or directory make: *\ [init.so] Error 1

Gem files will remain installed in /usr/local/lib/ruby/gems/1.9.1/gems/therubyracer-0.12.0 for inspection. Results logged to /usr/local/lib/ruby/gems/1.9.1/gems/therubyracer-0.12.0/ext/v8/gem_make.out

root@ramon:~/temp/test# gem install therubyracer -v 0.11.0beta8 --pre Fetching: therubyracer-0.11.0beta8-x86_64-linux.gem (100%) Successfully installed therubyracer-0.11.0beta8-x86_64-linux Installing ri documentation for therubyracer-0.11.0beta8-x86_64-linux 1 gem installed

I'm not sure if this is related or not: https://github.com/cowboyd/libv8/issues/109

And https://github.com/cowboyd/therubyracer/issues/262

I also trying to install older version of the rubyracer but it'd look into the ia32 target instead of the x64 (should be libv8-3.16.14.3-x86_64-linux/vendor/v8/out/x64.release instead of libv8-3.16.14.3-x86_64-linux/vendor/v8/out/ia32.release).

Because the 0.11.0beta8 works but the later one failed, I suspect it would be something up with the compilation script.

[sr3d]

I did some more researchs, and it turns out that TheRubyRacer calls Libv8.configure_makefile which relies on Libv8::Arch#libv8_arch to detect the architecture for the build.

The functions of interests are (in the libv8 gem: /ext/libv8/arch.rb)

def x64?
  if rubinius?
    x86_64_from_build_cpu || x86_64_from_arch_flag
  else
    x86_64_from_byte_length
  end
end

def arm?
  RbConfig::MAKEFILE_CONFIG['build_cpu'] =~ /^arm/
end

def libv8_arch
  if arm? then "arm"
  elsif x64? then "x64"
  else "ia32"
  end
end

def x86_64_from_byte_length
  ['foo'].pack('p').size == 8
end

['foo'].pack('p').size on the VPS returns 4, so I suspected the server is a 32-bit Ubuntu 10.04 running a 64-bit kernel. I was able to prove this:

root@ramon:~# file /sbin/init /sbin/init: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

while

root@ramon:~# uname -ar Linux ramon 3.9.3-x86_64-linode33 #1 SMP Mon May 20 10:22:57 EDT 2013 x86_64 GNU/Linux

Essentially TheRubyRacer got ia32 as the architecture as opposed to the x86_64, while the libv8 dependency is actually installed as x64. So what's the solution for this case? Switch to a 32bit kernel?

[ignisf]

hmm... Can I have the output of the file command for the ruby executable?

[ignisf]

I'm inclined to believe that that's an issue with Bundler, because it downloads a 64-bit binary version of the gem, instead of a version for the arch of ruby itself... I could be wrong. In fact, up until the initial bug reports for this issue appeared in the libv8 issue tracker I hadn't even considered running a 64-bit kernel w/ 32-bit userspace. I wonder what use cases are addressed by such a mix.

[sr3d]

@ignisf

Here's the file:

root@ramon:/var/www/staging.txtclouds.com/releases# file /usr/local/bin/ruby /usr/local/bin/ruby: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

The story with this server is that I set it up back in 2010-2011 timeframe with Ubuntu 10.04LTS. I think at the time I did not choose the 64bit version. Then a while ago Linode forced a kernel update to their latest kernel, which is the kernel I'm using (Latest 64 Bit (3.11.6-x86_84-linode35). Everything still worked fine with the new kernel in place.

The server was running TheRubyRacer 0.10.2 okay with Ruby 1.9.2p0 since day 1, until I upgraded to Rails 3.2.15 and latest version of jbuilder, which requires at least Ruby 1.9.3. I figured it's time to upgrade since Ruby 1.9.2p0 is way old and it will eventually be phased out, so I downloaded and compiled 1.9.3p484 from source, reran bundle, and then all hell broke loose... Now I can't even install back TheRubyRacer 0.10.2 with both Ruby 2.1.0 that's released today, or Ruby 1.9.3p484

[pglombardo]

I've been hitting the same issue for a week now with one app and now a second on the same host. :(

Ubuntu 12.04 uname -m shows x86_64 /usr/local/rbenv/versions/2.1.1/bin/ruby: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe9ea68773aea8824702a4a85bb3fde1007a8115c, not stripped

** [out :: vespina.dumana.com] compiling string.cc
 ** [out :: vespina.dumana.com] compiling handles.cc
 ** [out :: vespina.dumana.com] compiling signature.cc
 ** [out :: vespina.dumana.com] compiling locker.cc
 ** [out :: vespina.dumana.com] linking shared-object v8/init.so
 ** [out :: vespina.dumana.com] g++: error: /var/www/PasswordPusher/shared/bundle/ruby/2.1.0/gems/libv8-3.16.14.3-x86_64-linux/vendor/v8/out/ia32.release/obj.target/tools/gyp/libv8_base.a: No such file or directory
 ** [out :: vespina.dumana.com] g++: error: /var/www/PasswordPusher/shared/bundle/ruby/2.1.0/gems/libv8-3.16.14.3-x86_64-linux/vendor/v8/out/ia32.release/obj.target/tools/gyp/libv8_snapshot.a: No such file or directory
 ** [out :: vespina.dumana.com] make: *** [init.so] Error 1
 ** [out :: vespina.dumana.com]
 ** [out :: vespina.dumana.com] make failed, exit code 2
 ** [out :: vespina.dumana.com]
 ** [out :: vespina.dumana.com] Gem files will remain installed in /var/www/PasswordPusher/shared/bundle/ruby/2.1.0/gems/therubyracer-0.12.1 for inspection.
 ** [out :: vespina.dumana.com] Results logged to /var/www/PasswordPusher/shared/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0-static/therubyracer-0.12.1/gem_make.out
 ** [out :: vespina.dumana.com] An error occurred while installing therubyracer (0.12.1), and Bundler cannot
 ** [out :: vespina.dumana.com] continue.
 ** [out :: vespina.dumana.com] Make sure that `gem install therubyracer -v '0.12.1'` succeeds before bundling.
    command finished in 30643ms

Note the discrepency in the archetecture detection same as what @sr3d pointed out above.

Also, a manual install of the libv8 gem directly works:

gem install --install-dir ./shared/bundle/ libv8
Fetching: libv8-3.16.14.3.gem (100%)
Building native extensions.  This could take a while...
Successfully installed libv8-3.16.14.3
Parsing documentation for libv8-3.16.14.3
Installing ri documentation for libv8-3.16.14.3
Done installing documentation for libv8 after 6 seconds
1 gem installed

Without being too familiar with the codebase, it seems there possibly is an issue with Libv8.configure_makefile?

[pglombardo]

Also, ['foo'].pack('p').size returns 4 similarly. This is a VPS on Linode.

[kivikakk]

Also getting this (on Linode, hello!). Brand new 32-bit Ruby build on 64-bit kernel:

$ file `which ruby`
/usr/bin/ruby: ELF 32-bit LSB  shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=8f4b1ccd7094ab5098c20102ff2da6f2f5e037d0, not stripped
$ uname -a
Linux eiko 3.13.7-x86_64-linode38 #1 SMP Tue Mar 25 12:59:48 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

[Javex]

I have exactly the same problem now. This has been open for some time. Is there a fix to be expected? Or a workaround?

[Javex]

I have found a workaround that solved the problem, at least for me: Instead of installing a new ruby version using rvm install, I used rvm mount to use my system ruby. Then, installing worked because now the architectures seem to match...

[jfharden]

I'm having the same problem on Debian 7.8 (also in Linode I might add). I really want to avoid using my system ruby since that is 1.9.3 and I'd like to use a 2.x variant.

[mrdziuban]

Also on 32-bit Ubuntu with a 64-bit kernel. I solved this in a really hacky way:

# install 64-bit libv8
gem install libv8
# install 32-bit libv8
gem install libv8 --platform x86
# copy missing 32-bit files to 64-bit gem directory (replace paths as necessary)
cp -R /usr/local/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/libv8-3.16.14.11-x86-linux/vendor/v8/out/ia32.release /usr/local/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/libv8-3.16.14.11-x86_64-linux/vendor/v8/out/
# install therubyracer
gem install therubyracer

While this works, I'm not too happy with the solution. There's no way to specify that this needs to be done in my Gemfile and if I want to upgrade libv8 in the future, I'll need to do it all again.

[mrdziuban]

As an update to my previous comment, I found a better way around this issue. Using RVM (instead of rbenv), I forced the 32-bit version of Ruby to be installed:

rvm install 2.2.2 --32

After doing that, the 32-bit version of libv8 was installed by default and therubyracer installed without any problems.