LoadError when trying to require a .so.rb ruby file

Wow, this is a really weird case.

We use ".so" in the file being required to know we should look for extensions. We then search for .so, .jar, etc but never search for .so.rb. This is mostly the behavior of Ruby, but perhaps there's something we're missing.

I will say it's very questionable for the whois library to require files with .so at the end, since that's rather ambiguous...

Looking into it.

I will say it's very questionable for the whois library to require files with .so at the end, since that's rather ambiguous...

I agree, and I will probably change it. However, I reported it because all the other Ruby implementations worked and I thought you might want to give it a look.

According to MRI docs, it seems like this working in MRI is just a lucky coincidence. The docs claim that if it ends with .so or .o or whatever the platform-specific native library extension is, it will try to load it as an extension:

/*
 *  call-seq:
 *     require(string)    -> true or false
 *
 *  Ruby tries to load the library named _string_, returning
 *  +true+ if successful. If the filename does not resolve to
 *  an absolute path, it will be searched for in the directories listed
 *  in <code>$:</code>. If the file has the extension ``.rb'', it is
 *  loaded as a source file; if the extension is ``.so'', ``.o'', or
 *  ``.dll'', or whatever the default shared library extension is on
 *  the current platform, Ruby loads the shared library as a Ruby
 *  extension. Otherwise, Ruby tries adding ``.rb'', ``.so'', and so on
 *  to the name. The name of the loaded feature is added to the array in
 *  <code>$"</code>. A feature will not be loaded if its name already
 *  appears in <code>$"</code>. The file name is converted to an absolute
 *  path, so ``<code>require 'a'; require './a'</code>'' will not load
 *  <code>a.rb</code> twice.
 *
 *     require "my-library.rb"
 *     require "db-driver"
 */

I don't know if it is a coincidence or if MRI is smart enough to detect there's no shared extension with that name and tries to append .rb to the end.

This might be interesting to know, however I agree the behavior can be confusing.

Let's put it this way...I don't really want to fix this

A few more interesting cases...

Here, there's a .bundle that's not an extension (so I can see it blow up) and a .bundle.rb that's a ruby file. Ruby tries to load the .bundle:

~/projects/jruby ➔ cp foo.so.rb foo.bundle.rb

~/projects/jruby ➔ ruby -e "require 'foo.bundle'"
./foo.bundle: dlopen(./foo.bundle, 9): no suitable image found.  Did find: (LoadError)
	./foo.bundle: unknown file type, first eight bytes: 0x00 0xD2 0xBF 0x5F 0xFF 0x7F 0x00 0x00 - ./foo.bundle
	from -e:1

~/projects/jruby ➔ rm foo.bundle

~/projects/jruby ➔ ruby -e "require 'foo.bundle'"
ok

Now the same with a .so and a .so.rb:

~/projects/jruby ➔ ls foo.*
foo.bundle.rb	foo.so		foo.so.rb

~/projects/jruby ➔ ruby -e "require 'foo.so'"
ok

So this shows there's platform-specific logic here to attempt to load x.bundle as x.bundle before failing over to x.bundle.rb.

Now, a case you might expect to work: loading bar.rb.rb with require 'bar.rb':

~/projects/jruby ➔ cat bar.rb.rb
puts 'ok'

~/projects/jruby ➔ jruby -e "require 'bar.rb'"
LoadError: no such file to load -- bar
  require at org/jruby/RubyKernel.java:1037
   (root) at -e:1

~/projects/jruby ➔ ruby -e "require 'bar.rb'"
-e:1:in `require': no such file to load -- bar.rb (LoadError)
	from -e:1

So there's no failover to adding .rb if the extension is already .rb in the require argument. It only seems to failover for the "native" extensions like .bundle and .so.

How about .so.so:

~/projects/jruby ➔ cat baz.so.so 
puts 'ok'

~/projects/jruby ➔ ruby -e "require 'baz.so'"
-e:1:in `require': no such file to load -- baz.so (LoadError)
	from -e:1

But on my platform shared libs are .bundle:

~/projects/jruby ➔ mv baz.so.so baz.bundle.bundle

~/projects/jruby ➔ ruby -e "require 'baz.bundle'"
./baz.bundle.bundle: dlopen(./baz.bundle.bundle, 9): no suitable image found.  Did find: (LoadError)
	./baz.bundle.bundle: unknown file type, first eight bytes: 0x70 0x75 0x74 0x73 0x20 0x27 0x6F 0x6B - ./baz.bundle.bundle
	from -e:1

The logic in JRuby is basically this:

1. If no extension, search source extensions (.rb, .class) followed by extension extensions (.jar, .so, .bundle)
2. If source extension, search only source extensions (require 'foo.rb' will look for foo.rb and foo.class)
3. If extension extension, search only extension extensions (require 'foo.so' will look for foo.so, foo.jar, etc)

It seems like the extra logic would apply only to (3) above, failing over to .rb searching in the extension case.

Do we really need to fix this?

Do we really need to fix this?

I believe the answer is the response to the following question: is it a coincidence or a feature? In case it's just a coincidence, then MRI should probably fix this and make it less ambiguous. On the opposite, if it's a feature, you should probably consider it for JRuby as well.

I changed my tests so that the issue is no longer applicable. All the 3k tests now passes successfully with JRuby 1.6.0 RC3.

I'm going to open a ticket in the Ruby ML to see if someone else noticed this behavior before.

Thanks for your support.

Charles,

I know you read ruby-core, but for the records, here's the link to the ML
http://www.ruby-forum.com/topic/1248205

This fix makes it work, but breaks other things (presumably that depend on us normalizing extension extensions to ".jar" for searching purposes: https://gist.github.com/863022

Perhaps we should wait and see what ruby-core thinks about this failover behavior.

Simone: Thanks for posting that. I'll reply as well.

I think the logic can be found in the search_required function in eval.c. Not pretty.

I'm satisfied calling this "Won't Fix".

I believe the consistency from having .so and other extensions trigger an "extension load" in require is better than having to also do all the .rb searching on top of those extensions (which would slow extension file searches even more, and possibly load a .rb file when you really want it to load a .so.)

Workaround is to simply require the full name (foo.so.rb) if you know it's a .rb file.