Bugzilla Bug 161566

When trying to emerge rubygems on a new system installation, it goes into an
infinite loop and does not finish installation.

install dependency_list.rb
/var/tmp/portage/rubygems-0.8.11-r5/image/usr/lib/ruby/site_ruby/1.8/rubygems
install security.rb
/var/tmp/portage/rubygems-0.8.11-r5/image/usr/lib/ruby/site_ruby/1.8/rubygems
install gem_openssl.rb
/var/tmp/portage/rubygems-0.8.11-r5/image/usr/lib/ruby/site_ruby/1.8/rubygems
<--- lib/rubygems
<--- lib
  Successfully built RubyGem
  Name: sources
  Version: 0.0.1
  File: sources-0.0.1.gem
sandbox:  Caught signal 2 in pid 25374


Exiting on signal 2
sandbox:  Signal already caught and busy still cleaning up!
/usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:127:in `initialize': Interrupt
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:127:in `each'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:127:in
`initialize'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:109:in `new'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:109:in
`new_from_stream'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:441:in
`each_entry'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:439:in `loop'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:439:in
`each_entry'
        from /usr/lib/ruby/site_ruby/1.8/rubygems/package.rb:424:in `each'
         ... 15 levels...
        from setup.rb:710:in `__send__'
        from setup.rb:710:in `invoke'
        from setup.rb:674:in `invoke'
        from setup.rb:1352

/usr/portage/dev-ruby/rubygems/rubygems-0.8.11-r5.ebuild: src_install aborted;
exiting.

The signal 2 is me pressing Ctrl-C. The same thing also happens with
rubygems-0.9.0-r2.

Reproducible: Always

Steps to Reproduce:
1. emerge rubygems
2. post-install script hangs
3.




I can't reproduce this behavior on my home machine, so it may be related to
something strange on the server I'm trying to install on. I've looked around a
bit but nothing strikes me as odd or obvious. Any hints would be appreciated.

Some further investigation is turning up that the sources-0.0.1.gem file is not
properly read by the Tar code in package.rb. The tar headers are not proberly
read, and this throws the TarReader code into an endless loop. 

At this point I'm blaming my system as this happens with both versions of
rubygems and it doesn't happen on other systems. I just don't know which part
to blame yet. :-(

Some more debugging tonight led me to this part of lib/rubygems/package.rb,
starting at line 447. The first path using seek is the normal path and it
causes some unexpected result. Falling back to the second path makes the
rubygems installation work.

           if @io.respond_to? :seek
                # avoid reading...
                @io.seek(size - entry.bytes_read, IO::SEEK_CUR)
            else
                pending = size - entry.bytes_read
                while pending > 0
                    bread = @io.read([pending, 4096].min).size
                    raise UnexpectedEOF if @io.eof?
                    pending -= bread
                end
            end

As it turns out, the seek call actually seeks from the beginning of the file,
despite IO::SEEK_CUR being specified.

Interesting. From rb_io_seek_m() in io.c:

    int whence = SEEK_SET;

    if (rb_scan_args(argc, argv, "11", &offset, &ptrname) == 2) {
        whence = NUM2INT(ptrname);
    }

    return rb_io_seek(io, offset, whence);

so if for some reasons rb_scan_args fails, it will use SEEK_SET as you
described. I am not familiar with ruby source so I'm not sure what's going on
here (maybe I was tracking wrong function too ;).

I stumbled upon apparently the same bug. Everything works at home, but on the
server (which happens to be Gentoo Hardened) I can't install Rubygems.

When changing if @io.respond_to? :seek into if false, it installs successfully
(at least it doesn't complain) and later hangs similarily during RDoc install.

Removing old RubyGems RDoc and ri...
Installing rubygems-0.9.1 ri... //hangs here, I pressed ^C


RDoc failure in lib/rubygems/cmd_manager.rb at or around line 8 column 3
By the way, the line 8 of that file is
require 'rubygems/command'

Changing the code in rubygems as in comment 4 will only work around the
problem. In contrast to comment 3 the code in rb_io_seek_m is actually correct.
rb_scan_args is meant to fail when no second argument to @io.seek is given, so
that SEEK_CUR is the default when no argument is given.

All of this code works as expected, so the problem seems to lie in rb_io_seek
or beyond. For some reason SEEK_CUR is ignored and the actual seek call is done
with SEEK_SET instead, which causes the read error. Any code using seek will
have trouble with this. 

A vanilla ruby install on the machine doesn't have this problem, so it does
somehow get triggered by one of the options Gentoo applies. 

Thanks for the confirmation of the bug, I'm glad it's not just me. I don't use
hardened, BTW. Elmo, what arch are you building on and what CFLAGS do you use?

The arch is x86, CFLAGS="-O2 -march=pentium3 -pipe"

Elmo, can you confirm that you are currently using autoconf 2.61, and that
up/downgrading to autoconf 2.60 fixes this issue?

Perhaps to be a bit more clear: downgrade to autoconf-2.60, then re-emerge
ruby, and then emerging rubygems should work without problems.

Yes, that system has autoconf 2.61. However, I don't know if I can coerce the
root to downgrate autoconf just to make me happy. I'll try.

I can confirm downgrading to autoconf-2.60 and re-emerging ruby and rubygems
works  for me.

Adding base-system to Cc: because it is not clear to me if this is a bug in
ruby or a bug in autoconf.

to be honest, i'm very very doubtful that it's a bug in autoconf

that said, i unfortunately detest ruby greatly, so i dont really want to
investigate this issue ;)

I can confirm that downgrading autoconf to 2.60 then re-emerging ruby and
rubygems works properly.

Perhaps this is not a bug in autoconf, but it is a serious nuisance to us users
who DO like to use ruby.

SpanKY, I guess you don't like sliced bread either?  :-)

Anyway, what seems to happen is that ruby's configure.in includes the check 

  AC_FUNC_FSEEKO

With autoconf 2.60 this generates two tests that include fseeko, one labeled
"checking for _LARGEFILE_SOURCE value needed for large files" (which fails
because fseeko is undeclared in that test) and one to detect fseeko (which now
works because _LARGEFILE_SOURCE is defined to 1). The output then is:

  checking for _LARGEFILE_SOURCE value needed for large files... 1
  checking for fseeko... yes

With autoconf 2.61 the test for _LARGEFILE_SOURCE is generated differently, and
even though it still references fseeko it does seem to pass this time. After
that no test is done for fseeko itself, it is just defined, probably as a
side-effect form the _LARGEFILE_SOURCE test. The output is:

  checking for _LARGEFILE_SOURCE value needed for large files... no

(there is no line for fseeko).

So clearly something changed here going from 2.60 to 2.61. So either

1. the new autoconf test is broken and doesn't get the right result, or
2. the problem with ruby is not that its configure doesn't work correctly, but
that it's not using fseeko correctly.

I'll try to investigate this more during the weekend. 

which makes sense ... fseeko() is a lfs only command, so if _LARGEFILE_SOURCE
is irrelevant, than so is fseeko() ... that means the code should then be using
plain fseek()

With many thanks to flameeyes for working through the bug with me we came to
the conclusion that the problem is actually with glibc. The machine on which I
had the problems was still using glibc-2.3.6-r5 due to using the wrong profile.
After upgrading to glibc 2.4-r4, emerging autoconf-2.61, re-emerging ruby and
re-emerging rubygems things worked fine and the error was no longer there.
Could the other bug reporters also report their glibc version?

It's not fully clear if glibc 2.3 compatibility was broken with autoconf 2.61
or whether there is another reason that things just happened to work with
autoconf 2.60.

2.3.6-r5 over here. Thanks for sorting this out!

Just for your information, I masked autoconf-2.61 on hardened!

There is another one which probably has the same problem. Quoted from his
email:

Sorry, I couldn't confirm if this was a bug since I wasn't able to
come up with anything from a google search.

It does appear that this bug is the one I am running into.  I have the
same versions of glibc and autoconf.  I was able to install rubygems
by reverting back to autoconf 2.6.0.

This looks like it will be a problem for anyone doing a fresh install.
 My install is only two weeks old.

For what it's worth, I'm experiencing the same issue on a Thinkpad T40 (2006.1
brand new install Pentium M, x86 autoconf 2.6.1). I just tried it out on my
opteron (full 64 bit autoconf version 2.6.1) and it worked like a charm. So if
it is autoconf that's the culprit it isn't affecting me on a 64 bit system.

(In reply to comment #19)
> There is another one which probably has the same problem. Quoted from his
> email:
> 
> Sorry, I couldn't confirm if this was a bug since I wasn't able to
> come up with anything from a google search.
> 
> It does appear that this bug is the one I am running into.  I have the
> same versions of glibc and autoconf.  I was able to install rubygems
> by reverting back to autoconf 2.6.0.
> 
> This looks like it will be a problem for anyone doing a fresh install.
>  My install is only two weeks old.
> 

Doug, could you please indicate which version of glibc you are using on both
machines?

I'm not sure of the best way to give you that info, but:

x86:
 sys-libs/glibc-2.5 

opteron:
sys-libs/glibc-2.4-r4

So that's a difference.

I can update the version on the opteron and try it again if it will help.

Are you really sure that this is the same problem (emerge rubygems hangs) and
that you are using glibc-2.5 on the x86 machine? So far the problem has only
been seen with glibc-2.3 in combination with autoconf 2.61. I have just checked
on a x86 machine with glibc-2.5 but I can't reproduce the problem.

You can check the currently installed version with "emerge -s glibc".

As far as what I see happening, it's exactly the same behavior. It hangs at the
same spot, proc useage goes up to 100% for ruby and leavuing it running all
night doesn't help.

from the x86 machine:
bean ~ # emerge -s glibc
Searching...   
[ Results for search key : glibc ]
[ Applications found : 1 ]

*  sys-libs/glibc
      Latest version available: 2.5
      Latest version installed: 2.5
      Size of files: 15,876 kB
      Homepage:      http://www.gnu.org/software/libc/libc.html
      Description:   GNU libc6 (also called glibc2) C library
      License:       LGPL-2

Also for autoconf:
*  sys-devel/autoconf
      Latest version available: 2.61
      Latest version installed: 2.61
      Size of files: 1,364 kB
      Homepage:      http://www.gnu.org/software/autoconf/autoconf.html
      Description:   Used to create autoconfiguration files
      License:       GPL-2
and:

bean ~ # uname -a
Linux bean 2.6.19-gentoo-r5 #1 Fri Feb 9 13:17:21 CST 2007 i686 Intel(R)
Pentium(R) M processor 1500MHz GenuineIntel GNU/Linux

Is there anything else useful I can do?


(In reply to comment #23)
> Are you really sure that this is the same problem (emerge rubygems hangs) and
> that you are using glibc-2.5 on the x86 machine? So far the problem has only
> been seen with glibc-2.3 in combination with autoconf 2.61. I have just checked
> on a x86 machine with glibc-2.5 but I can't reproduce the problem.
> 
> You can check the currently installed version with "emerge -s glibc".
> 

This does not seem limited to hardened so removing CC: Please add back CC: 
if this is limited to only hardened

(In reply to comment #24)

> Is there anything else useful I can do?

One thing to try would be to downgrade to autoconf 2.60 and try to emerge first
ruby and then rubygems again. If it is the same problem then this should allow
rubygems to be installed. 

I can't reproduce this with glibc 2.5 and autoconf 2.61 on a Pentium M, though.

FYI: also waitig for ever here, I've not tried to downgrade autoconf yet...

Jan, if it takes longer than a few seconds then it makes no sense to wait any
longer. Which version of glibc and autoconf are you using, and on which arch?

I just ran into this on an x86 box that I hadn't upgraded in a long time as
well.
It was using glibc-2.3.6-r4 and autoconf-2.61. To fix, I had to upgrade to
glibc-2.5 and then "emerge ruby" from source again after upgrading glibc.

CC'ed hppa as this problem prevents ruby from being built on HPPA.
Latest available glibc is 2.3.6
Downgrading to autoconf-2.60 solves the problem.
Masking 2.61 like hardened did seems like a good idea.

FYI, what happens is that
miniruby mkconfig.rb (uses fseek) generates a gigantic rbconfig.rb:
-rw-r--r-- 1 root root 1074006987 Feb 22 12:36 rbconfig.rb
then tries to run it and ruby runs out of memory.

(In reply to comment #30)
> CC'ed hppa as this problem prevents ruby from being built on HPPA.
> Latest available glibc is 2.3.6
> Downgrading to autoconf-2.60 solves the problem.
> Masking 2.61 like hardened did seems like a good idea.

Did you test this on a HPPA system? The only thing that strikes me is that
`FEATURES=test emerge rubygems` fails, apparently because rubygems needs to be
installed to the live system before it can be tested. Otherwise, it emerges and
works fine.

(In reply to comment #31)
> (In reply to comment #30)
> > CC'ed hppa as this problem prevents ruby from being built on HPPA.

                               ^^^^^^^^^^^^^^^^

Try to emerge ruby. It doesn't build on a current (~)hppa box.
If you must know, I needed to update a ruby-based package, but it failed
because of a recent upgrade of coreutils which forces a remerge/update of ruby
which failed because of an upgrade of autoconf...

> Did you test this on a HPPA system?

How do you think I noticed compiling ruby fails on HPPA?

# uname -a
Linux gatsby 2.6.16.18-pa11 #1 SMP Tue Jun 27 19:22:19 CEST 2006 parisc PA8500
(PCX-W) 9000/785/J5000 GNU/Linux

# emerge --info
Portage 2.1.2-r10 (default-linux/hppa/2006.1, gcc-4.1.2, glibc-2.3.6-r5,
2.6.16.18-pa11 parisc)
=================================================================
System uname: 2.6.16.18-pa11 parisc PA8500 (PCX-W)
Gentoo Base System release 1.12.9
Timestamp of tree: Thu, 22 Feb 2007 13:50:01 +0000
dev-lang/python:     2.4.4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.23b
virtual/os-headers:  2.6.20
ACCEPT_KEYWORDS="hppa ~hppa"
AUTOCLEAN="yes"
CBUILD="hppa2.0-unknown-linux-gnu"
CFLAGS="-O2 -pipe -march=2.0"
CHOST="hppa2.0-unknown-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox
sfperms strict"
GENTOO_MIRRORS="ftp://polly.a.la.maison/gentoo
http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://polly/portage"
USE="berkdb bitmap-fonts cli cracklib crypt cups firefox foomaticdb fortran
gdbm hppa iconv imlib isdnlog libwww midi ncurses pcre perl pic pppd python
readline reflection ruby session spell spl ssl truetype-fonts type1-fonts xml2
xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty
extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null
plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse
evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216
lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS

> > > CC'ed hppa as this problem prevents ruby from being built on HPPA.

> Try to emerge ruby. It doesn't build on a current (~)hppa box.
> If you must know, I needed to update a ruby-based package, but it failed
> because of a recent upgrade of coreutils which forces a remerge/update of ruby
> which failed because of an upgrade of autoconf...
> 
> > Did you test this on a HPPA system?
> 
> How do you think I noticed compiling ruby fails on HPPA?

I assumed you inferred it from the use of certain versions of certain packages.

> # uname -a
> Linux gatsby 2.6.16.18-pa11 #1 SMP Tue Jun 27 19:22:19 CEST 2006 parisc PA8500
> (PCX-W) 9000/785/J5000 GNU/Linux

Very nice.

> # emerge --info
> ACCEPT_KEYWORDS="hppa ~hppa"

So it is dev-lang/ruby-1.8.6_pre1 that fails?

dev-lang/ruby-1.8.5_p2 builds fine on a stable system (although the test suite
fails), as do packages that depend on ruby. IMHO, masking a stable package in
order to get unstable packages to build on ~hppa systems does not make sense. 

IMHO, if unstable versions of ruby require certain versions of glibc, then
fixing [R]DEPEND for ruby does make sense and that seems to be the way to go.

No issue on hppa with glibc-2.5.

Don't try to merge that glibc, it's only available on my dev box for now :)

(In reply to comment #33)

> dev-lang/ruby-1.8.5_p2 builds fine on a stable system (although the test suite
> fails), as do packages that depend on ruby. IMHO, masking a stable package in
> order to get unstable packages to build on ~hppa systems does not make sense. 

Did you actually try to build ruby-1.8.2 after upgrading to autoconf 2.61? 

(In reply to comment #35)
> (In reply to comment #33)
> 
> > dev-lang/ruby-1.8.5_p2 builds fine on a stable system (although the test suite
> > fails), as do packages that depend on ruby. IMHO, masking a stable package in
> > order to get unstable packages to build on ~hppa systems does not make sense. 
> 
> Did you actually try to build ruby-1.8.2 after upgrading to autoconf 2.61? 

Naturally I did that before I commented on this bug. It emerges and works fine.

# qlop -lu sys-devel/autoconf-2 dev-lang/ruby dev-ruby/rubygems
Mon Dec  4 18:44:20 2006 >>> dev-lang/ruby-1.8.5_p2
Fri Jan  5 17:08:32 2007 <<< sys-devel/autoconf-2.60
Fri Jan  5 17:08:32 2007 >>> sys-devel/autoconf-2.61
Thu Feb 22 16:26:28 2007 >>> dev-ruby/rubygems-0.9.1
Thu Feb 22 16:29:03 2007 <<< dev-ruby/rubygems-0.9.1
Thu Feb 22 16:29:03 2007 >>> dev-ruby/rubygems-0.9.0-r2
Thu Feb 22 18:53:39 2007 >>> dev-lang/ruby-1.8.5_p2


One thing to note is that after re-emerging dev-lang/ruby-1.8.5_p2,
dev-ruby/rubygems-0.9.0-r2 (which is marked ~hppa) suddenly fails to re-emerge:

mkdir -p
/var/tmp/portage/dev-ruby/rubygems-0.9.0-r2/image/usr/lib/ruby/site_ruby/1.8/rbconfig
install datadir.rb
/var/tmp/portage/dev-ruby/rubygems-0.9.0-r2/image/usr/lib/ruby/site_ruby/1.8/rbconfig
<--- lib/rbconfig
<--- lib
hook
/var/tmp/portage/dev-ruby/rubygems-0.9.0-r2/work/rubygems-0.9.0/./post-install.rb
failed:
Invalid argument - sources-0.0.1.gem
Try 'ruby setup.rb --help' for detailed usage.

!!! ERROR: dev-ruby/rubygems-0.9.0-r2 failed.
Call stack:
  ebuild.sh, line 1614:   Called dyn_install
  ebuild.sh, line 1060:   Called qa_call 'src_install'
  environment, line 3161:   Called src_install
  rubygems-0.9.0-r2.ebuild, line 34:   Called ruby_src_install
  ruby.eclass, line 197:   Called ruby_einstall
  ruby.eclass, line 151:   Called die

!!! setup.rb install failed


The same happens with dev-ruby/rubygems-0.9.1 (which is p.masked).

(In reply to comment #33)
> > > > CC'ed hppa as this problem prevents ruby from being built on HPPA.
> 
> > Try to emerge ruby. It doesn't build on a current (~)hppa box.

Sigh!
There's no ~hppa version of glibc or autoconf, therefore it fails both on hppa
and ~hppa.

> > # emerge --info
> > ACCEPT_KEYWORDS="hppa ~hppa"
> 
> So it is dev-lang/ruby-1.8.6_pre1 that fails?

I didn't mention 1.8.6, did I?
ruby-1.8.6_pre1 is still p.masked

None of the ruby versions in portage build with the latest glibc2.3.6 +
autoconf-2.61, all build fine with autoconf-2.60, including p.masked
ruby-1.8.6_pre1.


hppa2.0-unknown-linux-gnu-gcc -O2 -pipe -march=2.0  -fPIC  -DRUBY_EXPORT  -I.
-I.  -c dmyext.c
hppa2.0-unknown-linux-gnu-gcc -O2 -pipe -march=2.0  -fPIC  -DRUBY_EXPORT  -I.
-I.  -c main.c
hppa2.0-unknown-linux-gnu-ar rcu libruby18-static.a array.o bignum.o class.o
compar.o dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o inits.o io.o
marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o
range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o
util.o variable.o version.o  dmyext.o
hppa2.0-unknown-linux-gnu-gcc main.o  libruby18-static.a -ldl -lcrypt -lm   -o
miniruby -O2 -pipe -march=2.0  -fPIC  -DRUBY_EXPORT   -rdynamic
-Wl,-export-dynamic 
hppa2.0-unknown-linux-gnu-gcc -shared -Wl,-soname,libruby18.so.1.8   array.o
bignum.o class.o compar.o dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o
inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o
prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o
struct.o time.o util.o variable.o version.o  dmyext.o -ldl -lcrypt -lm   -o
libruby18.so.1.8.5
rbconfig.rb updated
/var/tmp/portage/dev-lang/ruby-1.8.5_p2/work/ruby-1.8.5-p2/rbconfig.rb: failed
to allocate memory (NoMemoryError)
        from ./ext/extmk.rb:22:in `require'
        from ./ext/extmk.rb:22
make: *** [all] Error 1
gatsby ~ # cd /var/tmp/portage/dev-lang/ruby-1.8.5_p2/work/ruby-1.8.5-p2

gatsby ruby-1.8.5-p2 # ./miniruby mkconfig.rb 
rbconfig.rb updated

gatsby ruby-1.8.5-p2 # ls -l rbconfig.rb 
-rw-r--r-- 1 root root 1074002866 Feb 22 20:58 rbconfig.rb

gatsby ruby-1.8.5-p2 # tail -n15 mkconfig.rb 
open(rbconfig_rb, mode) do |f|
  if $timestamp and f.stat.size == config.size and f.read == config
    puts "#{rbconfig_rb} unchanged"
  else
    puts "#{rbconfig_rb} updated"
    f.rewind
    f.truncate(0)
    f.print(config)
  end
end
if String === $timestamp
  FileUtils.touch($timestamp)
end

# vi:set sw=2:


Dropping the truncate & rewind calls:

gatsby ruby-1.8.5-p2 # ./miniruby mkconfig.rb 
rbconfig.rb updated

gatsby ruby-1.8.5-p2 # ls -l rbconfig.rb 
-rw-r--r-- 1 root root 7090 Feb 22 21:01 rbconfig.rb

gatsby ruby-1.8.5-p2 # tail -n13 mkconfig.rb 
open(rbconfig_rb, mode) do |f|
  if $timestamp and f.stat.size == config.size and f.read == config
    puts "#{rbconfig_rb} unchanged"
  else
    puts "#{rbconfig_rb} updated"
    f.print(config)
  end
end
if String === $timestamp
  FileUtils.touch($timestamp)
end

# vi:set sw=2:

Created an attachment (id=111003) [details]
build.log

> There's no ~hppa version of glibc or autoconf, therefore it fails both on hppa
> and ~hppa.

I don't get at all what you mean by this. I remerged current stable ruby on a
second, current stable hppa system, (two of which I manage to maintain to
retain a stable Gentoo/HPPA distribution, basically my role in the HPPA team,
you might say):

[ebuild   R   ] dev-lang/ruby-1.8.5_p2  USE="ipv6 threads tk -cjk -debug -doc
-examples -socks5" 0 kB

and remerging ruby basically works as it should:

Thu Nov 30 22:40:41 2006 >>> sys-libs/glibc-2.3.6-r5
Tue Dec  5 15:07:49 2006 <<< dev-lang/ruby-1.8.5-r3
Tue Dec  5 15:07:49 2006 >>> dev-lang/ruby-1.8.5_p2
Sat Jan  6 21:26:10 2007 <<< sys-devel/autoconf-wrapper-3.2-r2
Sat Jan  6 21:26:10 2007 >>> sys-devel/autoconf-wrapper-4-r3
Sat Jan  6 21:34:40 2007 <<< sys-devel/autoconf-2.60
Sat Jan  6 21:34:40 2007 >>> sys-devel/autoconf-2.61
Thu Feb 22 21:17:58 2007 >>> dev-lang/ruby-1.8.5_p2

The build does not fail, I don't see that huge file, and I get a working
executable on which other packages can depend, on two current stable systems.

> > > # emerge --info
> > > ACCEPT_KEYWORDS="hppa ~hppa"
> > 
> > So it is dev-lang/ruby-1.8.6_pre1 that fails?
> 
> I didn't mention 1.8.6, did I?
> ruby-1.8.6_pre1 is still p.masked

You didn't mention any version so you left me guessing until you posted this
comment. :)

> None of the ruby versions in portage build with the latest glibc2.3.6 +
> autoconf-2.61, all build fine with autoconf-2.60, including p.masked
> ruby-1.8.6_pre1.

On a stable hppa system? Could you try (again) in a stable chroot? What USE
flags did you set for dev-lang/ruby? And if it fails in your stable chroot as
well, could you also see if upgrading your kernel (hppa-sources) to a 2.6.19
fixes it?

(In reply to comment #39)
> > There's no ~hppa version of glibc or autoconf, therefore it fails both on hppa
> > and ~hppa.
> 
> I don't get at all what you mean by this. 

There is no ~hppa version of glibc, i.e. latest is hppa
There is no ~hppa version of autoconf, i.e. latest is hppa
This problem is about <glibc-2.4 + =autoconf-2.61 + ruby (any ruby)
wrt this problem, hppa == ~hppa

> I remerged current stable ruby on a
> second, current stable hppa system, (two of which I manage to maintain to
> retain a stable Gentoo/HPPA distribution, basically my role in the HPPA team,
> you might say):
> 
> [ebuild   R   ] dev-lang/ruby-1.8.5_p2  USE="ipv6 threads tk -cjk -debug -doc
> -examples -socks5" 0 kB

That works here too, but not with all flags off which is what I have

[ebuild   R   ] dev-lang/ruby-1.8.6_pre1  USE="-debug -doc -examples -ipv6
-socks5 -threads -tk"

Tried all versions of ruby that are in portage before unmasking 1.8.6_pre1
I have no other umasked packages

> On a stable hppa system? Could you try (again) in a stable chroot? What USE
> flags did you set for dev-lang/ruby? And if it fails in your stable chroot as
> well, could you also see if upgrading your kernel (hppa-sources) to a 2.6.19
> fixes it?

Even tried with gcc-3 before upgrading gcc & glibc, same issue
Upgraded kernel, same issue
Just try without any USE flag (actually -threads is enough)

`USE="-*" emerge ruby` and wait for about 5 minutes.

(In reply to comment #40)
> Just try without any USE flag (actually -threads is enough)
> 
> `USE="-*" emerge ruby` and wait for about 5 minutes.

OK, so `USE=-threads emerge dev-lang/ruby` fails on any HPPA system (probably
any system with sys-libs/glibc-2.3).

Confirmed.

14:31:36 @<GMsoft> [ebuild   R   ] dev-lang/ruby-1.8.5_p2  USE="ipv6 -cjk
                   -debug -doc -examples -socks5 -threads -tk" 0 kB
14:31:59 @<GMsoft> [ebuild   R   ] dev-ruby/rubygems-0.9.0-r2  0 kB

That is from an experimental PARISC system with glibc-2.5. No problem there,
although it fails the same 4 tests that any x86 fails. Moving the dev-lang/ruby
problem to bug #168130. The dev-ruby/rubygems problem seems to be an entirely
different one so it can have this bug back now.

(In reply to comment #41)
> OK, so `USE=-threads emerge dev-lang/ruby` fails on any HPPA system (probably
> any system with sys-libs/glibc-2.3).

Which BTW is the default config

See also bug #8909 at RubyGems bugtracker at rubyforge.org (I've posted a patch
there).

For convenience the url is
http://rubyforge.org/tracker/index.php?func=detail&aid=8909&group_id=126&atid=575

(In reply to comment #44)
> See also bug #8909 at RubyGems bugtracker at rubyforge.org (I've posted a patch
> there).
> 

I had a quick look at your patch, but this is not the right approach to fix
this. The problem is actually related to broken or strange largefile support in
ruby, depending on a combination of glibc, autoconf, and ruby.

So even if the patch allows rubygems to be installed, you are likely to see
other strange bugs with other ruby applications using similar functions.

Just for the record, on sparc (64bit architecture, 32bit user mode), after
building ruby-<any> using autoconf-2.61, rubygems does not go into an infinite
loop --- it just fails to install.  Also, anything requiring gems to install
fails as well.

(This is with glibc-2.3.6-r5 on sparc.)

I found something about autoconf 1.6x in the ruby 1.8.6 changelog, so I thought
it would fix it. but did not. even with autoconf 1.60 I had no luck.

I downgraded to autoconf-2.59-r7 and it's all good now !

thanks 

If you need more info from my system, just ask.

(In reply to comment #49)

> If you need more info from my system, just ask.

Could you please indicate which glibc version you are using on which arch?

just wanted to notify you guys, that masking autoconf 2.61 causes esound to
fail (automake failed ..)

(In reply to comment #51)
> just wanted to notify you guys, that masking autoconf 2.61 causes esound to
> fail (automake failed ..)
> 

Is this related to ruby? If not, and if this is just an esound problem, perhaps
with the same underlying cause, then please open a new bug for it and reference
this one, so that the esound maintainers are also aware of it.

(In reply to comment #52)
> (In reply to comment #51)
> > just wanted to notify you guys, that masking autoconf 2.61 causes esound to
> > fail (automake failed ..)
> > 
> 
> Is this related to ruby?

No, this is why forcing downgrades (or blocking upgrades) is a bad idea. :)

HPPA has glibc-2.5 and autoconf-2.61 stable, rubygems installs with all the
bells and whistles (although the test suite fails one test because of a missing
file). So HPPA is out.

(In reply to comment #50)

sorry for the wait... here is all the details....

somekool@krypton ~ $ emerge --info
Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.3.6-r5,
2.6.19-suspend2-r1-justbudget i686)
=================================================================
System uname: 2.6.19-suspend2-r1-justbudget i686 Intel(R) Pentium(R) 4 CPU
2.40GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Wed, 11 Apr 2007 01:30:07 +0000
dev-java/java-config: 1.3.7, 2.0.31
dev-lang/python:     2.3.5-r3, 2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-pipe -O2 -march=pentium4"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/games/ggz /etc/gconf
/etc/java-config/vms/ /etc/php/apache1-php5/ext-active/
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-pipe -O2 -march=pentium4"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer nostrip sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en ja fr"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/home/somekool/.gentoo-overlays/enlightenment
/home/somekool/.gentoo-overlays/kolab2 /home/somekool/gentoo/portage.local"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X aac acl acpi alsa arts bash-completion berkdb bidi bindist bitmap-fonts
bl bonjour bzip2 cairo cdparanoia cdr cjk cli cpudetection cracklib crypt cups
dbus dga dri dts dv dvb dvd dvdr dvdread edl eds emboss encode fam firefox
fortran gcj gdbm ggi gif gpm hal i8x0 iconv immqt-bc isdnlog jack jpeg kde
layout-osx-like libg++ lirc live lm_sensors lzo mad matroska midi mikmod mmx
mmxext mp3 mpeg mplayer mysql mythtv ncurses nls nptl nptlonly objc ogg opengl
oss pam pcmcia pcre pdf perl png ppds pppd python qt qt3 qt4 quicktime readline
real reflection rtc ruby sdl session spell spl sqlite sse sse2 ssl svg tcpd tga
theora tordns truetype truetype-fonts type1-fonts unicode v4l v4l2
visualization vorbis wifi win32codecs x86 xcomposite xml xorg xv xvmc zeroconf
zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci
emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" LINGUAS="en ja fr" USERLAND="GNU" VIDEO_CARDS="i740 sis
vesa vga"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

somekool@krypton ~ $

(In reply to comment #47)
> Just for the record, on sparc (64bit architecture, 32bit user mode), after
> building ruby-<any> using autoconf-2.61, rubygems does not go into an infinite
> loop --- it just fails to install.  Also, anything requiring gems to install
> fails as well.
> 

On my sparc systems, this was the autoconf-2.61 difficulty; with autoconf-2.60,
I have:

fmccor@polylepis ~ [189]% eix rubygems
[I] dev-ruby/rubygems
     Available versions:  0.8.11-r6 (~)0.9.0-r2 (~)0.9.2
     Installed versions:  0.9.2(02:40:43 PM 05/07/2007)(doc examples server)
     Homepage:            http://rubyforge.org/projects/rubygems/
     Description:         Centralized Ruby extension management system

and have no problems installing -0.8.11-r6 then reinstalling -0.9.2

So, I am removing sparc from this bug (at least until someone runs into a
problem on sparc again).

(In reply to comment #54)

> somekool@krypton ~ $ emerge --info
> Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.3.6-r5,

You are still using glibc-2.3.*. Combined with autoconf 2.61 this causes the
ruby issues.

*** Bug 179573 has been marked as a duplicate of this bug. ***

(In reply to comment #54)

should I consider upgrading glibc? can this be really be done safely?

anyone found another solution for this problem with autoconf 2.61 ?

automake/aclocal is now crashing on multiple packages I am trying to emerge...
I suspect the cause the because I downgraded autoconf

*** Bug 179859 has been marked as a duplicate of this bug. ***

(In reply to comment #18)
> Just for your information, I masked autoconf-2.61 on hardened!

From the hardened POV, this bug is fixed ...

*** Bug 185512 has been marked as a duplicate of this bug. ***

Suggest that the ruby ebuilds depend either on:
1) <sys-devel/autoconf-2.61
or on:
2) >sys-libs/glibc-2.3*

I can confirm that you need one or the other, and the first choice is probably
a poor one.

I'm also not very happy to exclude anyone on a glibc-2.3-based system,
especially if ruby will actually work fine on it (provided that autoconf 2.61
isn't used there). I've explored a bit the different possibilities and checked
the profiles, but I just don't feel there is a good solution that can be
implemented in the ruby ebuild. 

Instead I will prepare a bug report for autoconf, as I believe that the problem
should be fixed there, either by masking autoconf 2.61 on systems with glibc
2.3 or by fixing the bug that reports the wrong result for glibc 2.3.

I am having all kinds of trouble here. I unmerged ruby and autoconf. emerged
autoconf-2.60, but then ruby wants autoconf-2.61 again! UGH! So I let it do
it's thing. but now rubygems fails:

19:38:26 (168.91 KB/s) - `/usr/portage/distfiles/rubygems-0.9.4.tgz' saved
[204841/204841]

 * checking ebuild checksums ;-) ...                                           
                                              [ ok ]
 * checking auxfile checksums ;-) ...                                          
                                              [ ok ]
 * checking miscfile checksums ;-) ...                                         
                                              [ ok ]
 * checking rubygems-0.9.4.tgz ;-) ...                                         
                                              [ ok ]
>>> Unpacking source...
>>> Unpacking rubygems-0.9.4.tgz to /var/tmp/portage/dev-ruby/rubygems-0.9.4/work
 * Applying rubygems-0.9.1-no_post_install.patch ...                           
                                              [ ok ]
 * Applying no-system-rubygems.patch ...                                       
                                              [ ok ]
 * Applying rubygems-0.9.1-no_rdoc_install.patch ...                           
                                              [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/dev-ruby/rubygems-0.9.4/work/rubygems-0.9.4 ...
/usr/bin/ruby: no such file to load -- auto_gem (LoadError)
 * 
 * ERROR: dev-ruby/rubygems-0.9.4 failed.
 * Call stack:
 *               ebuild.sh, line 1695:  Called dyn_compile
 *               ebuild.sh, line 1033:  Called qa_call 'src_compile'
 *               ebuild.sh, line   44:  Called src_compile
 *   rubygems-0.9.4.ebuild, line   38:  Called die
 * The specific snippet of code:
 *      ${RUBY} setup.rb config --libruby="/usr/$(get_libdir)/ruby" || die
"setup.rb config failed"
 *  The die message:
 *   setup.rb config failed

# emerge --info
Portage 2.1.3.16 (default-linux/x86/2007.0/desktop, gcc-3.3.6, glibc-2.3.6-r3,
2.6.19-gentoo-r5 i686)
=================================================================
System uname: 2.6.19-gentoo-r5 i686 Mobile Intel(R) Pentium(R) 4 - M CPU
2.00GHz
Timestamp of tree: Mon, 29 Oct 2007 00:30:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.3 [enabled]
app-shells/bash:     3.2_p17
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.3
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -mcpu=pentium4 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache1-php5/ext-active/
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -mcpu=pentium4 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks fixpackages metadata-transfer sandbox sfperms strict
unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://gentoo.llarian.net/pub/gentoo
http://gentoo.mirrors.tera-byte.com/ http://gentoo.llarian.net/"
LINGUAS="en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl acpi apache2 berkdb bitmap-fonts cairo cdr cli cracklib crypt dbus dri
dvd dvdr dvdread eds emboss encode esd evo fam firefox gdbm gif gpm gstreamer
hal iconv isdnlog jpeg kerberos ldap mad midi mikmod mp3 mpeg mudflap mysql
ncurses nptl nptlonly ogg opengl openmp oss pam pcre pdf perl php png pppd
python qt3 qt3support qt4 quicktime readline reflection ruby sdl session spell
spl ssl svg tcpd tiff truetype truetype-fonts type1-fonts unicode vorbis
win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ens1371" ALSA_PCM_PLUGINS="adpcm
alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa
lfloat linear meter mulaw multi null plug rate route share shm softvol"
ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy
fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon
rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l
vesa vga via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY

I just found something that worked. God bless this cat for posting and fixing
what this bug report couldn't...

http://fatpenguinblog.com/scott-rippee/usrbinruby-no-such-file-to-load-auto_gem-loaderror/

the solution is simply:

RUBYOPT="" emerge -av rubygems 

*** Bug 182826 has been marked as a duplicate of this bug. ***

*** Bug 168130 has been marked as a duplicate of this bug. ***

RUBYOPT="" emerge -av rubygems

did the trick for me, too

thanks, Daevid :)

Closing this bug since glibc-2.3 is positively old now and we have not seen any
duplicates or additional reports recently.