Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 161566 - rubygems goes into infinite loop while trying to install
Summary: rubygems goes into infinite loop while trying to install
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Ruby Team
URL:
Whiteboard:
Keywords:
: 168130 179573 179859 182826 185512 (view as bug list)
Depends on: 190177
Blocks:
  Show dependency tree
 
Reported: 2007-01-11 16:11 UTC by Hans de Graaff
Modified: 2008-10-14 12:27 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,15.76 KB, text/plain)
2007-02-22 20:10 UTC, Xavier Neys (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Graaff gentoo-dev 2007-01-11 16:11:55 UTC
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.
Comment 1 Hans de Graaff gentoo-dev 2007-01-11 19:18:22 UTC
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. :-(
Comment 2 Hans de Graaff gentoo-dev 2007-01-12 22:49:50 UTC
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.
Comment 3 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2007-01-13 06:03:39 UTC
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 ;).
Comment 4 Elmo Todurov 2007-01-17 09:27:19 UTC
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'
Comment 5 Hans de Graaff gentoo-dev 2007-01-18 15:20:07 UTC
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?
Comment 6 Elmo Todurov 2007-01-18 16:22:22 UTC
The arch is x86, CFLAGS="-O2 -march=pentium3 -pipe"
Comment 7 Hans de Graaff gentoo-dev 2007-01-18 16:24:17 UTC
Elmo, can you confirm that you are currently using autoconf 2.61, and that
up/downgrading to autoconf 2.60 fixes this issue?
Comment 8 Hans de Graaff gentoo-dev 2007-01-18 16:31:14 UTC
Perhaps to be a bit more clear: downgrade to autoconf-2.60, then re-emerge ruby, and then emerging rubygems should work without problems.
Comment 9 Elmo Todurov 2007-01-18 17:48:28 UTC
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.
Comment 10 Jason Waldhelm 2007-01-19 15:29:59 UTC
I can confirm downgrading to autoconf-2.60 and re-emerging ruby and rubygems works  for me.
Comment 11 Hans de Graaff gentoo-dev 2007-01-19 15:47:26 UTC
Adding base-system to Cc: because it is not clear to me if this is a bug in ruby or a bug in autoconf.
Comment 12 SpanKY gentoo-dev 2007-01-20 00:13:33 UTC
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 ;)
Comment 13 Al Hoang 2007-01-20 08:10:06 UTC
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.
Comment 14 Hans de Graaff gentoo-dev 2007-01-20 08:50:39 UTC
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. 




Comment 15 SpanKY gentoo-dev 2007-01-20 11:22:47 UTC
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()
Comment 16 Hans de Graaff gentoo-dev 2007-01-27 23:31:15 UTC
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.
Comment 17 Elmo Todurov 2007-01-27 23:34:03 UTC
2.3.6-r5 over here. Thanks for sorting this out!
Comment 18 Christian Heim (RETIRED) gentoo-dev 2007-01-28 21:09:52 UTC
Just for your information, I masked autoconf-2.61 on hardened!
Comment 19 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2007-01-29 03:51:49 UTC
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.
Comment 20 Doug Dressler 2007-02-11 04:49:39 UTC
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.
> 

Comment 21 Hans de Graaff gentoo-dev 2007-02-11 08:31:04 UTC
Doug, could you please indicate which version of glibc you are using on both machines?
Comment 22 Doug Dressler 2007-02-11 09:21:58 UTC
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.

Comment 23 Hans de Graaff gentoo-dev 2007-02-11 09:40:13 UTC
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".
Comment 24 Doug Dressler 2007-02-11 22:54:57 UTC
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".
> 

Comment 25 solar (RETIRED) gentoo-dev 2007-02-12 02:06:58 UTC
This does not seem limited to hardened so removing CC: Please add back CC: 
if this is limited to only hardened
Comment 26 Hans de Graaff gentoo-dev 2007-02-17 15:19:20 UTC
(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.
Comment 27 Jan Schubert 2007-02-18 14:12:13 UTC
FYI: also waitig for ever here, I've not tried to downgrade autoconf yet...
Comment 28 Hans de Graaff gentoo-dev 2007-02-18 14:15:49 UTC
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?
Comment 29 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-02-18 23:51:53 UTC
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.
Comment 30 Xavier Neys (RETIRED) gentoo-dev 2007-02-22 14:22:50 UTC
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.
Comment 31 Jeroen Roovers (RETIRED) gentoo-dev 2007-02-22 15:34:06 UTC
(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.
Comment 32 Xavier Neys (RETIRED) gentoo-dev 2007-02-22 15:59:25 UTC
(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



Comment 33 Jeroen Roovers (RETIRED) gentoo-dev 2007-02-22 18:27:37 UTC
> > > 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.
Comment 34 Guy Martin (RETIRED) gentoo-dev 2007-02-22 18:29:47 UTC
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 :)
Comment 35 Hans de Graaff gentoo-dev 2007-02-22 18:41:13 UTC
(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? 
Comment 36 Jeroen Roovers (RETIRED) gentoo-dev 2007-02-22 19:32:59 UTC
(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).
Comment 37 Xavier Neys (RETIRED) gentoo-dev 2007-02-22 20:09:10 UTC
(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:
Comment 38 Xavier Neys (RETIRED) gentoo-dev 2007-02-22 20:10:23 UTC
Created attachment 111003 [details]
build.log
Comment 39 Jeroen Roovers (RETIRED) gentoo-dev 2007-02-23 04:36:23 UTC
> 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?
Comment 40 Xavier Neys (RETIRED) gentoo-dev 2007-02-23 09:48:49 UTC
(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.
Comment 41 Jeroen Roovers (RETIRED) gentoo-dev 2007-02-23 13:32:03 UTC
(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.
Comment 42 Jeroen Roovers (RETIRED) gentoo-dev 2007-02-23 13:55:44 UTC
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.
Comment 43 Xavier Neys (RETIRED) gentoo-dev 2007-02-23 14:17:11 UTC
(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
Comment 44 nikolay karev 2007-02-27 09:41:43 UTC
See also bug #8909 at RubyGems bugtracker at rubyforge.org (I've posted a patch there).
Comment 45 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2007-02-27 09:53:12 UTC
For convenience the url is http://rubyforge.org/tracker/index.php?func=detail&aid=8909&group_id=126&atid=575
Comment 46 Hans de Graaff gentoo-dev 2007-02-27 14:03:54 UTC
(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.
Comment 47 Ferris McCormick (RETIRED) gentoo-dev 2007-04-20 14:36:19 UTC
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.
Comment 48 Ferris McCormick (RETIRED) gentoo-dev 2007-04-20 14:37:31 UTC
(This is with glibc-2.3.6-r5 on sparc.)
Comment 49 Mathieu Jobin 2007-04-23 12:42:32 UTC
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.
Comment 50 Hans de Graaff gentoo-dev 2007-04-30 13:36:20 UTC
(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?



Comment 51 Matt 2007-05-13 15:23:44 UTC
just wanted to notify you guys, that masking autoconf 2.61 causes esound to fail (automake failed ..)

Comment 52 Hans de Graaff gentoo-dev 2007-05-13 15:28:16 UTC
(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.
Comment 53 Jeroen Roovers (RETIRED) gentoo-dev 2007-05-15 23:15:27 UTC
(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.
Comment 54 Mathieu Jobin 2007-05-16 04:48:01 UTC
(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 ~ $
Comment 55 Ferris McCormick (RETIRED) gentoo-dev 2007-05-16 11:01:41 UTC
(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).
Comment 56 Hans de Graaff gentoo-dev 2007-05-17 11:05:37 UTC
(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.
Comment 57 Jakub Moc (RETIRED) gentoo-dev 2007-05-23 19:53:51 UTC
*** Bug 179573 has been marked as a duplicate of this bug. ***
Comment 58 Mathieu Jobin 2007-05-25 12:08:58 UTC
(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

Comment 59 Jakub Moc (RETIRED) gentoo-dev 2007-05-26 11:32:34 UTC
*** Bug 179859 has been marked as a duplicate of this bug. ***
Comment 60 Christian Heim (RETIRED) gentoo-dev 2007-07-07 10:20:53 UTC
(In reply to comment #18)
> Just for your information, I masked autoconf-2.61 on hardened!

From the hardened POV, this bug is fixed ...
Comment 61 Hans de Graaff gentoo-dev 2007-07-25 07:17:10 UTC
*** Bug 185512 has been marked as a duplicate of this bug. ***
Comment 62 Ferris McCormick (RETIRED) gentoo-dev 2007-08-18 14:10:46 UTC
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.
Comment 63 Hans de Graaff gentoo-dev 2007-08-25 14:34:40 UTC
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.
Comment 64 Daevid Vincent 2007-10-29 02:44:38 UTC
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


Comment 65 Daevid Vincent 2007-10-29 03:12:18 UTC
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 
Comment 66 Jakub Moc (RETIRED) gentoo-dev 2007-10-29 07:21:05 UTC
*** Bug 182826 has been marked as a duplicate of this bug. ***
Comment 67 Jakub Moc (RETIRED) gentoo-dev 2007-10-29 07:22:44 UTC
*** Bug 168130 has been marked as a duplicate of this bug. ***
Comment 68 Matt 2007-11-26 22:58:33 UTC
RUBYOPT="" emerge -av rubygems

did the trick for me, too

thanks, Daevid :)
Comment 69 Hans de Graaff gentoo-dev 2008-10-14 12:27:16 UTC
Closing this bug since glibc-2.3 is positively old now and we have not seen any duplicates or additional reports recently.