I try to setup gentoo with USE="ntpl userlocales", CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe". Bootstrap is ok, but emerge system fails at gcc-3.4.2-r2: mkinstalldirs='/bin/sh /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/mkinstalldirs' \ /bin/sh mklibgcc > tmp-libgcc.mk xgcc: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2/specs: No such file or directory mv tmp-libgcc.mk libgcc.mk TARGET_CPU_DEFAULT="" \ HEADERS="ansidecl.h" DEFINES="" \ /bin/sh /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/mkconfig.sh tconfig.h /var/tmp/portage/gcc-3.4.2-r2/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.4.2-r2/work/build/gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -fno-stack-protector-all -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc -I/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/. -I/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \ -c /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o xgcc: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2/specs: No such file or directory make[1]: *** [crtbegin.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/gcc-3.4.2-r2/work/build/gcc' make: *** [all-gcc] Error 2 !!! ERROR: sys-devel/gcc-3.4.2-r2 failed. !!! Function gcc_do_make, Line 1036, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r2 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.7-gentoo-r14 i686) ================================================================= System uname: 2.6.7-gentoo-r14 i686 Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X apm arts avi berkdb bitmap-fonts crypt cups encode f77 foomaticdb gdbm gif gnome gpm gtk gtk2 imlib jpeg kde libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcpd truetype x86 xml2 xmms xprint xv zlib"
is this from inside a chroot?
*** Bug 68919 has been marked as a duplicate of this bug. ***
Yes, it is from chroot of bilding system. Also I try "emerge sync" to -r3 and emerge again: it ends with same exact error.
Interest thing: I have working gcc-3.4.2-r2 on system, it was upgraded from 3.4.1 or 3.4.2-r1.
Andrew if you read the thread you will see this is during an install all the tarballs are using gcc 3.3 this is only a problem during a chroot a normal system appears to update without failure.
if you just run "unset GCC_SPECS" does that fix the problem? if so, then it would be a known bug that should be 'fixed' now that we dont specify GCC_SPECS in the gcc configs by default... but to get that fix without re-emerging anything just edit the main config in /etc/env.d/gcc/ to remove any mention of GCC_SPECS. if you use a specs-specific config (like, say, x86_64-pc-linux-gnu-3.4.2-hardened), for now you will have to unset GCC_SPECS after chrooting to clear that variable from your environment.
this does fix the problem maybe it is time to get the stage packages updated?
at the moment the only stable that should worry is amd64 stable, and our 2004.3 testing stages already have the fix (unless i misunderstood jhuebel).
if the 2004.3 already have the fix why aren't they up under experimental so we can get it tested an moved out to stable? That would make more sence then having a bug report for something as stupid as this wouldn't it?
With unset GCC_SPECS gcc-3.4.2-r3 emerges successfilly. Thanks for help.
*** Bug 68395 has been marked as a duplicate of this bug. ***
*** Bug 70437 has been marked as a duplicate of this bug. ***
*** Bug 70184 has been marked as a duplicate of this bug. ***
With my gcc-3.4.3 emerged, I was unable to compile anything. I have set GCC_SPECS in /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3 to: GCC_SPECS="/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs" rerun gcc-config and source /etc/profile et voila :)
Adding myself to Cc list (since I was on Cc for bug #70437 which has now been closed as a duplicate). Isn't this bug going to affect all ~x86 people who upgrade from 3.4.2* to 3.4.3? If so, the ebuild either needs masking or fixing - leaving it in its current state is going to cause quite a lot of unnecessary grief... Phil
*** Bug 70456 has been marked as a duplicate of this bug. ***
this is going to effect some users who migrate, I stopped setting the GCC_SPECS variable for the default config shortly after it was pointed out to me that it's never unset. martin: you might want to remove that and type "unset GCC_SPECS" instead. vapier: perhaps we should set a different variable in the gcc configs and have the wrapper translate that to GCC_SPECS before calling gcc? or some other gcc-config voodoo?
gcc-config-1.3.7-r3 now performs sanity checking on GCC_SPECS (makes sure it exists) before exporting it into the env
The current test seems to check for a sane environment value for GCC_SPECS. However right before that it loops over all profiles, sourcing them all. And since my "default" profile doesn't set GCC_SPECS at all (not to "" or anything, it's just not in there at all) GCC_SPECS gets set in the grand loop, then never unset, and makes it into /etc/env.d/05gcc no matter what profile I choose. Now I know this hardened thing can be nice and everything, but I still want it off when I choose to :) I haven't tried remerging gcc yet. Is that supposed to fix it by setting GCC_SPECS to something in the default non-hardened profile? or is this a bug that should be handled in gcc-config, possibly by unsetting GCC_SPECS (and possibly other things too) before sourcing things?
very true 1.3.7-r4 unsets GCC_CONFIG before sourcing the one the user has chosen
*** Bug 73264 has been marked as a duplicate of this bug. ***
*** Bug 73305 has been marked as a duplicate of this bug. ***
using gcc-config 1.3.7-r4 with only gcc-3.4.3-r1 (just emerged both), it stills fucks up GCC_SPECS and LD_PATH env variables : i choosed : i686-pc-linux-gnu-3.4.3 but it generated the following /etc/env.d/05gcc file : PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.3" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.4.3" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3/info" LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/3.4.3:/usr/lib/gcc/i686-pc-linux-gnu/3.4.3:/usr/lib/gcc/i686-pc-linux-gnu/3.4.3:/usr/lib/gcc/i686-pc-linux-gnu/3.4.3" GCC_SPECS="/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/hardened.specs" see how LD_PATH contains 4 times the same value and the GCC_SPECS is set to an hardened one should this one be reopened ?
the LDPATH is not a new thing and is an unrelated bug ... it's also not a critical bug at all as for GCC_SPECS ... i'm retarted and spelled the var wrong in 1.3.7-r4 ... i'll look into fixing LDPATH before releasing 1.3.7-r5
ok i just put out 1.3.7-r5 which has my stupid variable name fixed and i updated the code to trim multiple LDPATHs
*** Bug 75165 has been marked as a duplicate of this bug. ***
