Bug #4941: cannot load such file -- rubygems.rb (LoadError)

• Status: Rejected
• Assignee: usa (Usaku NAKAMURA)
• Target version: -
• ruby -v: ruby 1.9.3dev (2011-06-28 trunk 32265) [i386-mswin32_90]

[lazaridis.com (Lazaridis Ilias)]

=begin

From within the directory of a fresh trunk checkout:

$ win32\configure
$ nmake
$ miniruby -e"p 'hello'" #=> hello
$ ruby -e"p 'hello'"

internal:gem_prelude:1:in require': cannot load such file -- rubygems.rb (LoadError) from <internal:gem_prelude>:1:in '

(the exact same procedure using branch 1.9.2 worked fine)
=end

[lazaridis.com (Lazaridis Ilias)]

Correct formatting:

$ win32\configure
$ nmake
$ miniruby -e"p 'hello'" #=> hello
$ ruby -e"p 'hello'"

[usa (Usaku NAKAMURA)]

• Category changed from ext to core
• Status changed from Open to Rejected
• Assignee set to usa (Usaku NAKAMURA)

It's spec.
We don't support to run ruby without installation.

[shyouhei (Shyouhei Urabe)]

In other words, you have to nmake install before you run the ruby.exe.

[nobu (Nobuyoshi Nakada)]

And, to run the installed ruby not just built one, you have to chdir to another directory than the build directory.

[lazaridis.com (Lazaridis Ilias)]

Usaku NAKAMURA wrote:

It's spec.
We don't support to run ruby without installation.

Even if you have such a specification (which is a very bad one for a dynamic interpreted language), you should possibly verify it's strictness.

I mean, I just want the freshly compiled interpreter to say "hello" - and this fails? Although any libraries are one directory away?

1.9.2 works fine, like expected, out-of-the-source-tree.

1.9.3 is blocked (by the rubygems subsystem) to work out-of-the-source-tree, and this has not much to do with "specs" but with bugs. This should be solved (thus rubygems behaves like an integral part of ruby).

If rubygems is so intrusive, that it can leave ruby "alone" to simply work, then it (rubygems) should be possibly enabled later (e.g. by nmake install).

So, independent of the specs, this issue here exists and should be solved.

[usa (Usaku NAKAMURA)]

Sorry, I can't understand what you want to say in reality.
(It's the limitation of my English skill, not your problem.)

Anyway, present behavior is a result of reaching after the long
long discussion.
If you want to change it, create new Feature ticket and persuade
people who have the power to decide ruby's specification.

[lazaridis.com (Lazaridis Ilias)]

Usaku NAKAMURA wrote:

Sorry, I can't understand what you want to say in reality.
(It's the limitation of my English skill, not your problem.)

I cannot always describe my point of view understandable to others.

So, I have to apologize.

Anyway, present behavior is a result of reaching after the long
long discussion.
If you want to change it, create new Feature ticket and persuade
people who have the power to decide ruby's specification.

Fine, will possibly do so.

[lazaridis.com (Lazaridis Ilias)]

• File gem_prelude.diff gem_prelude.diff added

rubygems should not block ruby from running.

The attached WORKAROUND(!) patch "gem_prelude.diff" removes the blocking behaviour of rubygems, thus the interpreter works (as in versions before) after the compilation from within the source-tree.

I hope the issue becomes a bit more clear now.

[wishdev (John Higgins)]

Unfortunately - you did not properly configure your ruby build and that was the issue - there is clearly the --disable-rubygems option in the configure file which is more than happy to turn off the requirement of RubyGems (notice the if defined?(Gem) statement prior to requiring rubygems).

As to the issue of earlier versions working differently - they do not work differently - you have 1.9.2 already installed and that is what the system picked up when you built 1.9.2 earlier. 1.9.3 does not see the 1.9.2 version of rubygems.rb and therefore couldn't run with it.

You did not build you ruby properly to allow you to get the experience you wanted - this is not something that requires a patch to the build system or ruby itself.

[drbrain (Eric Hodel)]

This patch does not pick up the proper rbconfig.rb nor compiled executables like zlib, socket or openssl.

Look at how the Makefile uses miniruby for correct usage.

Running tests:

./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext --
"./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext --"

Building ri data:

./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext --
"./bin/rdoc" --encoding=UTF-8 --no-force-update --all --ri --op ".ext/rdoc" "."

Installing ruby:

./miniruby -I./lib -I. -I.ext/common ./tool/rbinstall.rb
--make="make" --dest-dir="" --extout=".ext" --mflags="" --make-flags=""
--data-mode=0644 --prog-mode=0755 --installed-list .installed.list --install=all --rdoc-output=".ext/rdoc"

[lazaridis.com (Lazaridis Ilias)]

• File gem_prelude_v2.diff gem_prelude_v2.diff added

Eric Hodel wrote:

This patch does not pick up the proper rbconfig.rb

Based on my tests, ./rbconfig.rb is the correct file ("nmake test" uses the same file).

Please correct if this is wrong.

nor compiled executables like zlib, socket or openssl.
[...]

The patch was a quick workaround, to make things work for me and to demonstrate that it's not necessary to block ruby when running from the source tree.

I've attached an updated patch, which adds 4 directories to the $LOAD_PATH (those should be all relevant ones).

The patch is still a workaround, if you reopen the issue, then I (or we) can workout on a production-quality patch.

[nobu (Nobuyoshi Nakada)]

It doesn't sound like an unreasonable limit to need to be installed before running, on many platforms, shared libraries are loaded from fixed paths.
I don't want to include the workaround since it is not used after installation at all.

[lazaridis.com (Lazaridis Ilias)]

Nobuyoshi Nakada wrote:

It doesn't sound like an unreasonable limit to need to be installed before running, on many platforms, shared libraries are loaded from fixed paths.
I don't want to include the workaround since it is not used after installation at all.

Please forget about the condition "installed".

This issue is about the condition "compiled". About the behaviour of the ruby-interpreter within the source-tree, right after the compilation.

• Rubygems should not block the freshly compiled interpreter from working within the source tree.

I'm not asking to include a workaround, but to resolve this issue in some production-quality manner.

Specification should be:

• Status compiled : interpreter works as-is within the source-tree
• Status installed: interpreter depends on directories specified during the installation

[lazaridis.com (Lazaridis Ilias)]

Lazaridis Ilias wrote:
[...]

Specification should be:

• Status compiled : interpreter works as-is within the source-tree

This could be as simple as loading a file like rurbydev.rb or rbcustom.rb or similar, prior to require rubygems.

Is there any such kind of file that ruby loads by default?

[luislavena (Luis Lavena)]

Nobuyoshi Nakada wrote:

It doesn't sound like an unreasonable limit to need to be installed before running, on many platforms, shared libraries are loaded from fixed paths.

On Ruby0s wiki for committers:

http://redmine.ruby-lang.org/projects/ruby/wiki/CommitterHowto

• Always build Ruby outside of $(srcdir)
• Always build Ruby inside of $(srcdir) too, using ./configure.

In neither of both cases ruby is usable straight away without playing with RUBYLIB to ensure the proper paths are used.

This is noticed when you need to load any extension or library that is part of stdlib.

That never worked since I remember.

That is one of the reasons I personally install before doing manual testing on the produced Ruby.

[nobu (Nobuyoshi Nakada)]

• ruby -v changed from ruby 1.9.3dev (2011-06-28 trunk 32265) [i386-mswin32_90] to -

Hi,

At Sat, 2 Jul 2011 15:38:57 +0900,
Lazaridis Ilias wrote in [ruby-core:37731]:

• Status compiled : interpreter works as-is within the source-tree

$ make runruby TESTSCRIPT=script_whatever_you_want_to_run

--
Nobu Nakada

[lazaridis.com (Lazaridis Ilias)]

Nobuyoshi Nakada wrote:

Hi,

At Sat, 2 Jul 2011 15:38:57 +0900,
Lazaridis Ilias wrote in [ruby-core:37731]:

• Status compiled : interpreter works as-is within the source-tree

$ make runruby TESTSCRIPT=script_whatever_you_want_to_run

"Make" is a build/make tool.

"ruby" is a dynamic interpreted language, far more powerful than a make tool. ruby should be able to operate autonomously as soon as possible.

The new mechanism to load rubygems, introduced in 1.9.3dev, disables a "newborn" ruby, and this is to be rated as a "bug" (or at least: "unnecessary loss of flexibility"):

$ ruby -e"p 'hello'" #=> fails with the error reported in this issue

Mr. Nakada,

you have deleted the "ruby -v" in this issue:

"ruby -v changed from ruby 1.9.3dev (2011-06-28 trunk 32265) [i386-mswin32_90] to -"

This issue was introduced by r30538 in the current trunk (ruby 1.9.3dev):

http://redmine.ruby-lang.org/projects/ruby-19/repository/revisions/30538/diff

Even if you do not accept this issue as a bug, the "ruby -v" I reported is correct (I cannot restore it myself, can you please do so?).

[wishdev (John Higgins)]

The new mechanism to load rubygems, introduced in 1.9.3dev, disables a "newborn" ruby, and this is to be rated as a "bug" (or at least: "unnecessary loss of flexibility"):

$ ruby -e"p 'hello'" #=> fails with the error reported in this issue

I will say it again - this is not a bug but a misconfiguration by yourself for your build.

win32\configure --disable-rubygems
nmake
ruby -e"p 'hello'"

Will work just fine for you. There is no reason for anything else to be done here. If you are not installing the build then you don't need rubygems because you won't have it setup anyways.

[nobu (Nobuyoshi Nakada)]

• ruby -v changed from - to ruby 1.9.3dev (2011-06-28 trunk 32265) [i386-mswin32_90]

Sorry, deleting "ruby -v" was a mistake. I'm not sure why/how it happened.

[lazaridis.com (Lazaridis Ilias)]

Nobuyoshi Nakada wrote:

Sorry, deleting "ruby -v" was a mistake. I'm not sure why/how it happened.

No problem, thank you.

[lazaridis.com (Lazaridis Ilias)]

John Higgins wrote:
[...]

win32\configure --disable-rubygems

I don't want to disable rubygems. What I want is described in this issue, which is rejected.

So we can leave it here.

[stevegoobermanhill (stephen gooberman-hill)]

Hi,
I'm not sure that this is a non-issue. I have been cross compiling ruby for an ARM embedded device. I am compiling on i686 machine build#, for arm-linux machine target#

The target machine setup is
target# ls -l /usr/local
/usr/local -> /mnt/flash #initially empty

so on my build machine I create a new directory matching the target machine directory
build# mkdir /mnt/flash

I will install ruby into this directory, then copy it over onto the target machine. The build and target machine have exactly the same paths for the built ruby installation, so lib/ruby etc are all in exactly the same places.

Now I build ruby on the build machine
build# ./configure --host=arm-linux --build=i686-linux CC=path/to/arm-cc --prefix /mnt/flash
...
build# make;make install

then copy /mnt/flash on build to /mnt/flash on target

then try running
target# ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [i386-linux]

target# irb
irb(main):001:0>

but

target# ruby -e 'p "hello"'
internal:gem_prelude:1:in require': cannot load such file -- rubygems.rb (LoadError) from <internal:gem_prelude>:1:in '

I can workaround this issue by

target# ruby --disable-gems -e 'p "hello"'
"hello"

but surely I shouldn't have to. My understanding is that the install process should build everything correctly onto a bare machine, no matter what architecture.

Thoughts?

Steve

[detomastah (Łukasz Pełszyński)]

This behavior is not a standard behavior. I don't know any other UNIX application, which requires installation before running.

Why should I install after every recompilation? Would installation let me test Ruby faster? Can you answer that?

[nobu (Nobuyoshi Nakada)]

It's very common for applications which make shared libraries.