For GCC 3.4.2 and higher the gcc libraries are installed in /usr/lib/gcc instead of /usr/lib/gcc-lib as before. It seems as if gcc-config doesnt know about that change. So it's always complaining about: Profile does not exist or invalid setting for /etc/env.d/gcc/xxx (gcc profile switching works nevertheless almost in every case, see below) looking at the source in /usr/bin/gcc-config shows why: @line 460: --- CC_COMP_NO_SPECS=$(echo ${CC_COMP} | awk -F- '{ print $1"-"$2"-"$3"-"$4"-"$5 }') if [ ! -d "/usr/lib/gcc-lib/${CC_COMP_NO_SPECS%-*}/${CC_COMP_NO_SPECS##*-}" -o \ ! -f "/etc/env.d/gcc/${CC_COMP}" ] then eerror "$0: Profile does not exist or invalid setting for /etc/env.d/gcc/${CC_COMP}" #exit 1 fi --------- There is no handling of the new path. The problem exists in both 1.3.6 and 1.3.7. As said above: Under normal circumstances the problem wont harm the system as switching works correctly. It just throws out the error message. But: During a bootstrap.sh(using gcc-1.3.6) things get messed up because of this. gcc-config places the error string in /etc/env.d/gcc/config and of course everything breaks.I didnt take a deeper look why that actually happens, because things work correctly if we correct the path handling in gcc-config. I include a sample patch for gcc-cong 1.3.6-r3.(maybe someone should look over it, i have no almost no experience with bash coding ;) ) It fixes the path handling of gcc-config at that point. Gcc profile switching works then without error message. Also bootstrap works fine. CU Imago Reproducible: Always Steps to Reproduce: 1. emerge >=gcc-3.4 2. gcc-config 2 Actual Results: gcc-config shows error: /usr/sbin/gcc-config: Profile does not exist or invalid setting for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.x Expected Results: no error message ;) discussion about that issue in forums: http://forums.gentoo.org/viewtopic.php?t=189250&start=276
Created attachment 44780 [details, diff] patch for gcc-config-1.3.6-r3 addes handling of new path for gcc libraries in >=gcc-3.4
just seen bug: #72555 which describes the bootstrap failure because of this gcc-config problem(at least i think so)
According to the post at http://forums.gentoo.org/viewtopic.php?p=1817027#1817027, this can be fixed by copying /usr/lib/gcc and /usr/lib/gcc-lib over each other. # cp -r /usr/lib/gcc /usr/lib/gcc-lib # cp -r /usr/lib/gcc-lib /usr/lib/gcc
@ #3 hmm that would mean to have the libs twice on your hdd ... as the devs seems to intended that new path for gcc>=3.4 (according to toolchain.eclass) the correct way must be to fix gcc-config, not linking/copying the libraries around ;)
Yes but this is only a temporary solution of course.
oh WOW.... i'm sorry guys, i thought this was taken care of a long time ago, before i removed the gcc->gcc-lib symlink hack from the ebuilds. for the immediate fix that we've been using until recently (due to gentoo utils other than just gcc-config), just make gcc a symlink to gcc-lib.
fixed in cvs.
*** Bug 72555 has been marked as a duplicate of this bug. ***
sys-devel/gcc-3.4.3 and sys-devel/gcc-3.4.3-r1 do not RDEPEND on gcc-config-1.3.6-r4 which was released to fix the bug mentioned here. Currently gcc-3.4.3 and gcc-3.4.3-r1 both contain RDEPEND=>=sys-devel/gcc-config-1.3.1 Based on this, I believe gcc-3.4.3 and gcc-3.4.3-r1 should contain RDEPEND=>=sys-devel/gcc-config-1.3.6-r4 If you run a bootstrap of a stage1 that contains a gcc-config less than 1.3.6-r4 but greater than or equal to 1.3.1 it will not be upgraded when gcc-3.4.3 is installed. The next package installed (glibc in bootstrap at that point) will fail because gcc no longer works, because it's profile is broken.
fixed.
