When the Ruby debugger bails out with an obscure error message (Linux 64-bit)

Posted by ericp on 2013-04-29 09:55
OS: Linux | Product: Komodo | tags: 64bit linux ruby debugging

When I try to use the Ruby debugger, on a 64-bit Linux machine, stops after giving this error message:

Error: cannot load such file --

What should I do?


So trace_nums.so is a Ruby C-extension that is used by the debugger, and
normally can be completely ignored. It was a bit puzzling why Ruby wasn't
loading this file, as it was clearly present and on Ruby's library load

I got the customer who reported this problem to fire up irb, cd'ed to
the directory containing trace_nums.so, and run `require 'trace_nums19'`.
He reported this error message:

irb(main):002:0> require './trace_nums19'
LoadError: libruby.so.1.9: cannot open shared object file: No such file or
directory -
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from (irb):2
        from /usr/bin/irb:12:in `<main>'

The customer had /usr/lib/libruby-1.9.1.so installed, but not libruby-so.1.9
I see that rvm installs libruby.so.1.9.1 in each directory, and then
creates symbolic links libruby.so and libruby.so.1.9 pointing to it, so the
libruby-so.M-N form looks correct. But this naming is inconsistent -- Python
puts the version numbers before the ".so" extension, while Perl and Ruby
typically put them after.

Anyway, the simple fix was to run

cd /usr/lib
sudo ln -s libruby-1.9.1.so libruby.so.1.9

ActiveState Staff
Tue, 2013-08-20 17:10

On my machine the libruby package had a slightly different variation:

sudo ln -s libruby-1.9.1.so.1.9.1 libruby.so.1.9

If neither work just have a look inside the /usr/lib folder and see what libruby package your OS decided to install :P

ls -ls /usr/lib/libruby*

- Carey