With Ruby 2.0.0 rev38184 as as BASERUBY, however with no luck:
snip
...
extracting ripper.y from ../../parse.y
ruby ../../tool/id2token.rb --vpath=../.. id.h ../../parse.y > ripper.tmp.y
ruby ./tools/preproc.rb ripper.tmp.y --output=ripper.y
rm -f ripper.tmp.y
compiling compiler ripper.y
bison -t -v -oy.tab.c ripper.y
sed -f ../../tool/ytab.sed -e "/^#/s!y.tab.c!ripper.c!" y.tab.c > ripper.c
generating eventids1.c from ../../parse.y
ruby ./tools/generate.rb --mode=eventids1 --ids1src=../../parse.y --output=eventids1.c
generating eventids2table.c from ./eventids2.c
ruby ./tools/generate.rb --mode=eventids2table --ids2src=./eventids2.c --output=eventids2table.c
make[1]: Leaving directory /tmp/ruby-snapshot20121210-11545-1p4tbw0/ruby-2.0.0-r38296/ext/ripper' generating miniprelude.c ruby -I. ./tool/compile_prelude.rb ./prelude.rb miniprelude.c /usr/share/rubygems/rubygems/defaults.rb:43:in join': can't convert nil into String (TypeError)
from /usr/share/rubygems/rubygems/defaults.rb:43:in default_dir' from /usr/share/rubygems/rubygems/specification.rb:621:in default_specifications_dir'
from /usr/share/rubygems/rubygems/specification.rb:637:in each_default' from /usr/share/rubygems/rubygems/specification.rb:678:in load_defaults'
from /usr/share/rubygems/rubygems.rb:1088:in <top (required)>' from <internal:gem_prelude>:1:in require'
from internal:gem_prelude:1:in `'
make: *** [miniprelude.c] Error 1
prerequisites failed
It seems that the ruby -I. ./tool/compile_prelude.rb ./prelude.rb miniprelude.c command is executed from the temporary directory with fresh sources. However, since there is added current directory '.' into the load path, the rbconfig.rb available there gets precedence instead of the rbconfig.rb of BASERUBY. Unfortunately, that rbconfig.rb contains just some rubbish.
The attached patch might fix the issue, but I am not sure what it breaks, since the original commit message introducing this flag (r14271) is not overly descriptive :/
This issue was solved with changeset r38303.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
common.mk ($(MINIPRELUDE_C)): -I may break make dist.
patched by Vit Ondruch [Bug #7541] [ruby-core:50736]
Those patch don't fit this issue because ruby 2.0 still can't be use for BASERUBY of Ruby 1.9.3 or prior.
I still don't understand what is the issue, why older ruby works and 2.0 does not work. So keep the '-I.' and add '--disable-gems' could fix the issues as well.
This is an issue of rubygems.
I would not blame RubyGems. Yes, they are doing more then they used to do, but requiring wrong rbconfig is definitely not issue of RubyGems, but issue of the build configuration. I would say that change in RubyGems just made the issue apparent, so fix in RubyGems will be fix in wrong place IMO.
Those patch don't fit this issue because ruby 2.0 still can't be use for BASERUBY of Ruby 1.9.3 or prior.
I still don't understand what is the issue, why older ruby works and 2.0 does not work. So keep the '-I.' and add '--disable-gems' could fix the issues as well.
RubyGems uses the information in rbconfig.rb like RbConfig::CONFIG["libdir"].
Previous gems works even if RbConfig::CONFIG["libdir"] is nil,
but the one bundled with 2.0 raises exception.
So 2.0 doesn't work.
-I is not acceptable because it doesn't load correct rbconfig.rb.
--disable-gems is not acceptable because it doesn't work for 1.8.
This issue was solved with changeset r38327.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
tool/make-snapshot: add --disable-rubygem to both MINIRUBY and RUBY.
On making miniprelude.c, it seems use MINIRUBY. this fixes #7541
but rubygems also needs to be fixed for older rubies.
-I is not acceptable because it doesn't load correct rbconfig.rb.
Ah, so the presumably wrong rbconfig.rb is correct one. Wouldn't be safer to not relay on rbconfig at all and take the information from some other place instead, e.g. config.status?
-I is not acceptable because it doesn't load correct rbconfig.rb.
Ah, so the presumably wrong rbconfig.rb is correct one.
Yes, such incomplete rbconfig.rb is also a correct one to make a package.
Wouldn't be safer to not relay on rbconfig at all and take the information from some other place instead, e.g. config.status?
Yeah, it can be, and simply it can take info from reading and parsing rbconfig.rb instead of loading.
But for example ruby 1.9.3's build process can't be changed, so this must be fixed by ruby 2.0's side.
Updated by 
Updated by 
Updated by