Last page or so of console: gzipping man page: who.1 gzipping man page: whoami.1 gzipping man page: yes.1 info: gzipping GNU info page: coreutils.info prepallstrip: strip: strip: bin/[ bin/chgrp bin/chown bin/chmod bin/cp bin/dd bin/dircolors bin/du bin/install bin/link bin/ln bin/dir bin/vdir bin/ls bin/mkdir bin/mkfifo bin/mknod bin/mv bin/nohup bin/readlink bin/rm bin/rmdir bin/shred bin/stat bin/sync bin/touch bin/unlink bin/cat bin/cksum bin/comm bin/csplit bin/cut bin/expand bin/fmt bin/fold bin/head bin/join bin/md5sum bin/nl bin/od bin/paste bin/pr bin/ptx bin/sha1sum bin/sort bin/split bin/sum bin/tac bin/tail bin/tr bin/tsort bin/unexpand bin/uniq bin/wc bin/basename bin/date bin/dirname bin/echo bin/env bin/expr bin/factor It hangs right there and has to be killed. I am running a full ~x86 system. Reproducible: Always Steps to Reproduce: 1. emerge -puDv world 2. 3. emerge info Portage 2.0.49-r7 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r1, 2.6.0-test5-love1) ================================================================= System uname: 2.6.0-test5-love1 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz distcc 2.11 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.2 [enabled] ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache autoaddcvs sandbox" GENTOO_MIRRORS="ftp://planetmirror.com/pub/gentoo ftp://mirror.aarnet.edu.au/pub/gentoo ftp://ftp.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage/" USE="x86 oss foomaticdb gpm jpeg libg++ libwww mad mikmod ncurses nls png quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb slang readline bonobo svga tcltk java guile X sdl tcpd pam ssl perl python esd imlib qt motif scanner -3dfx -3dnow acpi alsa apache2 apm arts avi cdr crypt cups dvd emacs encode gif -gnome gtk gtk2 kde mmx mozilla mpeg oggvorbis opengl pdflib sse"
thats a portage bug ... run strace and see what it's doing ... and/or watch the portage process with `lsof` ...
I can confirm this, except that my try to install it hangs at /bin/sync. Looking at top I see that the 'file' command is taking all of the CPU. Killing the emerge gets the system back to normal. Although I re-emerged the old coreutils before rebooting since I'm not to fond of having a half-installed package.
I tried adding the strace data as a tar.bz2, but he form wouldn't let me. I tried adding the uncompressed file, and got: The file you are trying to attach is 4272 kilobytes (KB) in size. Non-patch attachments cannot be more than 2000 KB. If your attachment is an image, try converting it to a compressable format like JPG or PNG, or put it elsewhere on the web and link to it from the bug's URL field or in a comment on the bug. Grrr! :) I'll try uploading just the last couple of hundred k, which should be enough??
Created attachment 18485 [details] strace data part 1 of 3
Created attachment 18486 [details] strace data part 2
Created attachment 18487 [details] strace data part 3
I have the same problem, except mine hangs once it gets to bin/sync. Here is my emerge --info Portage 2.0.49-r7 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r1, 2.4.22) ================================================================= System uname: 2.4.22 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="ftp://gentoo.noved.org/ http://gentoo.noved.org/ ftp://gentoo.mirrors.pair.com/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ libwww mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm slang readline svga java X sdl gpm tcpd pam ssl python imlib oggvorbis qt kde motif opengl -3dnow alsa -arts apache2 -berkdb cdr dvd -esd flash -gtk -gnome mysql pda perl samba sse usb"
Well just realized that changing my CFLAGS from "-march=pentium4 -O3 -pipe -fomit-frame-pointer" to "-march=pentium3 -O3 -pipe -fomit-frame-pointer" was enough to let the install go just fine. Can somebody explain why?
Nicely spotted Andreas. The prepstrip script is hanging when it executes the following command: f=$(file "${x}") where ${x} is the coreutils binary named "true". It looks like compiling and linking the "true" binary with gcc-3.3.1 and pentium4 in CFLAGS creates a binary that sends file-4.x into an endless loop: Using gcc-3.3.1 with march=pentium4: # gcc -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -o true true.o ../lib/libfetish.a # file ./true *** hangs here *** Using gcc-3.3.1 with march=pentium3: # gcc -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -o true true.o ../lib/libfetish.a # file ./true ./true: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped Using gcc-3.2.3: # gcc -march=pentium4 -O2 -pipe -fomit-frame-pointer -fPIC -o true true.o ../lib/libfetish.a # file ./true ./true: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped
Would you say that this is a gcc bug or something wrong with the 'file' utility?
sorry to rain on the p4 bashing parade =) but i've got the exact same hang on a dual athlon-mp... "file" eats 100% of the cpu and must be killed.
My emerge hung at /bin/sync as well and was "fixed" by switching my CFLAGS from -march=pentium4 to pentium3. # emerge info Portage 2.0.49-r7 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r1, 2.4.21-pfeifer-r1_pre4) ================================================================= System uname: 2.4.21-pfeifer-r1_pre4 i686 Intel(R) Pentium(R) 4 CPU 1.60GHz ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/ share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs sandbox userpriv ccache" GENTOO_MIRRORS="ftp://mirror.iawnet.sandia.gov/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync6.us.gentoo.org/gentoo-portage" USE="x86 oss apm arts avi crypt encode foomaticdb gif gtk imlib jpeg kde gnome libg++ libwww mad mikmod mmx motif mpeg ncurses nls oggvorbis opengl pdflib png qt quicktime sdl spell svga truetype xml2 xmms xv zlib gdbm berkdb slang readline gpm tcpd pam perl python acpi apache2 cups java postgres ssl -X"
I went generic and tried i686 for my cflags, migrating from athlon-mp and i still result in the same hang at the same place. interestingly enough though, setting my cflag to pentium3 causes the ebuild to work just fine! very strange...
Azarah, any ideas what could cause this ?
Its prob a gcc optimization bug. Tests this side works fine with gcc-3.3.1-r4.
This really isn't a portage bug... and it hasn't been touched in almost two months, so I'm gonna close it and assume it's "fixed". Someone can reopen and take it if they would like.
