Project

General

Profile

Actions

Bug #7541

closed

Can't use Ruby 2.0.0 as as BASERUBY

Added by vo.x (Vit Ondruch) over 11 years ago. Updated over 6 years ago.

Status:
Closed
Target version:
ruby -v:
ruby 2.0.0dev (2012-12-04 trunk 38184) [x86_64-linux]
[ruby-core:50736]

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

Updated by vo.x (Vit Ondruch) over 11 years ago

Alternatively, there could be used --disable-gems I think.

Actions #2

Updated by naruse (Yui NARUSE) over 11 years ago

  • 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.


Updated by naruse (Yui NARUSE) over 11 years ago

  • 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.

Updated by vo.x (Vit Ondruch) over 11 years ago

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.

Updated by naruse (Yui NARUSE) over 11 years ago

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.

Actions #6

Updated by naruse (Yui NARUSE) over 11 years ago

  • 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.

Updated by naruse (Yui NARUSE) over 11 years ago

  • Status changed from Closed to Assigned

Updated by vo.x (Vit Ondruch) over 11 years ago

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?

Updated by naruse (Yui NARUSE) over 11 years ago

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.

Updated by drbrain (Eric Hodel) about 11 years ago

  • 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?

Updated by vo.x (Vit Ondruch) about 11 years ago

  • Subject changed from Can't use Ruby 2.0.0 as as BASERUBY to Can&#x27;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

Updated by vo.x (Vit Ondruch) over 6 years ago

  • Status changed from Assigned to Closed

This is not relevant anymore and was probably resolved already.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0