Bugzilla Bug 68799

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