When trying to update gcc from 3.2.3-r1 to 3.3.2-r5 on a simple rescue system, I get this error: mkdir libgcc if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi ./xgcc -B./ -B/usr/i586-pc-linux-gnu/bin/ -isystem /usr/i586-pc-linux-gnu/include -isystem /usr/i586-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -DHAVE_SYSLOG -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -D_LIBC_PROVIDES_SSP_ -I. -I. -I/var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/gcc -I/var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/gcc/. -I/var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/gcc/config -I/var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/gcc/../include -DL_muldi3 -c /var/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/gcc/libgcc2.c -o libgcc/./_muldi3.o /bin/sh: -c: line 1: syntax error near unexpected token `(' /bin/sh: -c: line 1: `( nm -pg libgcc/./_muldi3.o | gawk 'NF == 3 { print "\t.hidden", $3 }'; cat libgcc/() { /bin/ls --color=auto --format=vertical "libgcc/./_muldi3.oS"' make[3]: *** [libgcc/./_muldi3.oS] Error 2 make[3]: Leaving directory `/var/tmp/portage/gcc-3.3.2-r5/work/build/gcc' make[2]: *** [libgcc.a] Error 2 make[2]: Leaving directory `/var/tmp/portage/gcc-3.3.2-r5/work/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/gcc-3.3.2-r5/work/build/gcc' make: *** [bootstrap-lean] Error 2 !!! ERROR: sys-devel/gcc-3.3.2-r5 failed. !!! Function src_compile, Line 435, Exitcode 2 !!! (no error message) The base system is fully up-to-date otherwise: sphere / # emerge -Dpuv --nospinner system These are the packages that I would merge, in order: Calculating system dependencies ...done! [ebuild U ] sys-devel/gcc-3.3.2-r5 [3.2.3-r1] -X -bootstrap -build -java -multilib +nls -nogcj -static 0 kB Total size of downloads: 0 kB Reproducible: Always Steps to Reproduce: 1. emerge -uv --nospinner gcc Actual Results: See attached script for details. Expected Results: Build gcc. :) Portage 2.0.50-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.4.24-sphere-2) ================================================================= System uname: 2.4.24-sphere-2 i586 AMD-K6(tm) 3D processor Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=k6 -funroll-loops -pipe" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=k6 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://192.168.1.2/gentoo ftp://ftp.easynet.nl/mirror/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://192.168.1.1/gentoo-portage" USE="acl apm berkdb crypt doc encode foomaticdb gdbm gif gtk gtk2 guile imap imlib ipv6 jpeg krb4 libg++ libwww mad maildir mbox mikmod mmx monitor mysql nas ncurses nls oggvorbis oss pam pdflib png postgres python readline samba skey spell ssl tetex tiff unicode x86 xml xml2 zlib"
Created attachment 26898 [details] script of build attempt
neither of those gcc versions are in portage anymore, please re-open this bug if the problem occurs with newer releases.
Still happens with gcc-3.3.3-r6.
Created attachment 37217 [details] Build attempt of gcc-3.3.3-r6 on 2004-08-11
Please don't attach binary files. We ignore them.
It's just a bzip2-compressed text file. I don't want to waste bandwidth with files that have such a high redundancy (original: 186139 Bytes, bz2: 16105 Bytes => compress ratio 11:1). If you really don't want to uncompress it yourself, tell me so and I'll attach it uncompressed.
I just was able to build gcc on that host. After pruning the environment ("env - TERM=$TERM /bin/bash --login") it worked fine. I'd suggest doing something similar within Portage, only exporting some known-"good" environment variables.
always attatch attatchments as text. Uncompressing it wastes our time. Pruning ${TERM} might be something for portage...
OK, I'll attach uncompressed text files in future. What's the maximum size deemed acceptable for attachments (I'll put bigger files on my homepage then)?
Portage should rather whitelist environment variables than blacklist them. Especially shell functions (e.g. "ls() { /bin/ls --color=auto "$@" ; }") might have unexpected and hard-to-debug effects. The user can still set non-whitelisted env vars in /etc/portage/bashrc if (s)he really intends to do that (instead of having them set by accident). It wasn't TERM that caused Portage to fail (as you can see above, I passed it through to Portage), but some other environment variable. I strongly suspect a shell function like the one given above, but didn't have time (it's a very slow host) to verify that.
Created attachment 50286 [details] Output of "env" on the failing host FWIW, these are the environment variables set in a root shell on that host.
The problem is the function 'dir()' - unset it, and it will work. I've just filed a minor-bug with patch to gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22213
do you use custom 'set' options to export functions to subshells ?
I just use export -f for those functions: ls() { /bin/ls --color=auto "$@" ; } ll() { /bin/ls -l "$@" ; } dir() { /bin/ls --color=auto --format=vertical "$@" ; } vdir() { /bin/ls --color=auto --format=long "$@" ; } ols() { /bin/ls "$@" ; } export -f ls ll dir vdir ols
dont do that
