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