Bug #7541
closed
Can't use Ruby 2.0.0 as as BASERUBY
Added by vo.x (Vit Ondruch) about 12 years ago.
Updated about 7 years ago.
Description
=begin
I am trying to prepare source archive using
tool/make-snapshot tmp
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 :/
Files
Alternatively, there could be used --disable-gems I think.
- Status changed from Open to Closed
- % Done changed from 0 to 100
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.
- Status changed from Closed to Assigned
- Assignee set to drbrain (Eric Hodel)
- % Done changed from 100 to 0
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.
This is an issue of rubygems.
naruse (Yui NARUSE) wrote:
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.
vo.x (Vit Ondruch) wrote:
naruse (Yui NARUSE) wrote:
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.
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
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.
- Status changed from Closed to Assigned
naruse (Yui NARUSE) wrote:
-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?
vo.x (Vit Ondruch) wrote:
naruse (Yui NARUSE) wrote:
-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.
- Category set to lib
- Target version set to 2.6
This appears to be a chicken and egg problem, but I don't have enough information to know how to solve it.
Should RubyGems know not to load when run as BASERUBY? How should RubyGems determine this?
- Subject changed from Can't use Ruby 2.0.0 as as BASERUBY to Can't use Ruby 2.0.0 as as BASERUBY
=begin
I was able to build ruby:
$ tool/make-snapshot tmp branches/ruby_2_0_0
using
ruby 2.0.0dev (2013-02-08 trunk 39161) [x86_64-linux]
So this is probably resolved. Can anybody confirm?
=end
- Status changed from Assigned to Closed
This is not relevant anymore and was probably resolved already.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0