I had gcc-3.4.5-r1 and gcc-3.4.6-r1 installed. I did "emerge -C gcc-3.4.5-r1". At the end, I got the following error message: --- !empty dir /etc * Scanning libtool files for hardcoded gcc library paths... gcc-config error: Could not run/locate "gcc" :0: assertion failed: (gcc -dumpversion) | getline NEWVER) >>> Regenerating /etc/ld.so.cache... When I now run "gcc", I get: [23:08:23 vz6tml@dewuga01:~] $ gcc /usr/bin/gcc-config: line 658: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.5: Datei oder Verzeichnis nicht gefunden * /usr/bin/gcc-config: Profile does not exist or invalid setting for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.5 /etc/env.d/gcc/i686-pc-linux-gnu-3.4.5 doesnt exist gcc-config error: Could not run/locate "gcc" I suppose, this is because I have multislot in the USE flags? [ebuild R ] sys-devel/gcc-3.4.6-r1 USE="multislot nls -bootstrap -boundschecking -build -doc -fortran -gcj -gtk -hardened -ip28 -nocxx -nopie -nossp -objc -vanilla" 0 kB [23:11:43 vz6tml@dewuga01:~] $ emerge --info Portage 2.1_pre7-r5 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r5-enx.02 i686) ================================================================= System uname: 2.6.15-gentoo-r5-enx.02 i686 Intel(R) Xeon(TM) CPU 2.80GHz Gentoo Base System version 1.12.0_pre17 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.15.92.0.2-r10, 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/Gentoo/Portage/distfiles" FEATURES="autoconfig buildpkg ccache collision-protect distcc metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="de_DE.UTF-8" LINGUAS="de" MAKEOPTS="-j11" PKGDIR="/Gentoo/Portage/Packages" PORTAGE_TMPDIR="/Gentoo/Portage/build" PORTDIR="/Gentoo/Portage/tree" PORTDIR_OVERLAY="/Gentoo/Portage/local-tree/misc" SYNC="rsync://localhost:10873/gentoo-portage" USE="x86 7zip acl apache2 async avi bash-completion berkdb bzip2 cap caps ccache checkpath cli cracklib crypt discard-path dri ecc extensions firefox gdbm gif glep glibc-omitfp gpm hpn iconv input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jikes jpeg kdeenablefinal libg++ libwww linuxthreads-tls logrotate lynxkeymap mmx motif moznoirc mozsvg mpm-threadpool multislot ncurses nis nls no-old-linux noaudio nocd nodrm nolvm1 nopop3d nptl nptlonly offensive pam pcre pdflib perl png posix pppd python readline recode reflection reiserfs sendfile server session sftplogging sharedmem spl sse ssl static sysvipc szip tcpd threads underscores unicode usb utf8 video_cards_ati vim-pager xfs xinetd xorg yp zlib elibc_glibc kernel_linux linguas_de userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS
this is because you had gcc-3.4.5 selected and then you cleaned it out without changing your compiler over to gcc-3.4.6 adding a call to 'do_gcc_config' in 'gcc-compiler_pkg_prerm' should fix up lazy users such as yourself :P
(In reply to comment #1) > this is because you had gcc-3.4.5 selected and then you cleaned it out without > changing your compiler over to gcc-3.4.6 Yes, that seems to be very much the reason. > adding a call to 'do_gcc_config' in 'gcc-compiler_pkg_prerm' should fix Great. > up lazy > users such as yourself :P "lazy", eh? :P Laziness is a virtue :)
ok, fixed with gcc-config-1.3.13-r2 and latest toolchain.eclass
seems the fix wasnt thought out enough, reverting
*** Bug 134095 has been marked as a duplicate of this bug. ***
*** Bug 131719 has been marked as a duplicate of this bug. ***
*** Bug 141564 has been marked as a duplicate of this bug. ***
*** Bug 179271 has been marked as a duplicate of this bug. ***
I'm not sure we should even worry about this case. It seems like it isn't something that comes up very often (based upon the activity of the bug), and fixing it seemed to be even more messy. Reopen and smack me if you disagree...
*** Bug 271554 has been marked as a duplicate of this bug. ***
*** Bug 305817 has been marked as a duplicate of this bug. ***
I have this happen everytime I remove a GCC version. I would be fine with a fix that wouldn't allow a GCC version to be removed when its the active version (and a note about gcc-config). (As a footnote: Just calling gcc-config may not fix the problem -- or rather it may create new problems: every once in a while it's important to rebuild a few key libraries before removing the old version and it's shared libraries.)
*** Bug 272240 has been marked as a duplicate of this bug. ***
I did an "emerge -v sys-devel/gcc" which upgraded me from gcc-4.5.3-r2 to gcc-4.5.4. The new gcc worked after the upgrade, but the emerge did generate a gcc-config error and trip an assertion: * Running 'fix_libtool_files.sh 4.5.3' * Scanning libtool files for hardcoded gcc library paths... * gcc-config: Active gcc profile is invalid! gcc-config: error: could not run/locate 'gcc' :0: assertion failed: (gcc -dumpversion) | getline NEWVER) >>> Regenerating /etc/ld.so.cache... >>> Original instance of package unmerged safely. * Switching native-compiler to i686-pc-linux-gnu-4.5.4 ... >>> Regenerating /etc/ld.so.cache... [ ok ] This seems to be related to the problem reported in this bug, though not nearly as severe. Is this another manifestation of this bug, or a separate problem that should have its own bug report?
Just got caught with this :( If the automated selection is not practical and the resolution is just running "gcc-config 1" then how about changing the warning message to include this command as a suggested fix? In what circumstances would "gcc-config 1" not be the complete solution? Alternatively the problem, error and solution could be added to the "Gentoo GCC Upgrade Guide" page for easy discovery.
(In reply to bluenuht from comment #15) there is no guarantee that the first profile is the right one. with cross-compilers and being able to install multiple gcc versions at the same time, "1" could be any target.
(In reply to SpanKY from comment #16) > (In reply to bluenuht from comment #15) > > there is no guarantee that the first profile is the right one. with > cross-compilers and being able to install multiple gcc versions at the same > time, "1" could be any target. OK. In that case is there an easy way the ebuild can detect the number of profiles? Or, at the very least suggesting the fix to be list your profiles and then select one? ... gcc-config error: Could not run/locate "gcc" Please select a gcc profile from this list shown when running >gcc-config -l with the command >gcc-config <PROFILE NUMBER> I really hate it when computers make me select from a list with only one item, but in some cases it does make it clear what is being selected for you.
Making a note that after upgrade, I had to manually remove the old gcc version from the `gcc-config -l` list Following the instructions from here: https://wiki.gentoo.org/wiki/Upgrading_GCC#Short_Version # emerge -u '>=sys-devel/gcc-4.9' # gcc-config -l [1] x86_64-pc-linux-gnu-4.8.3 * [2] x86_64-pc-linux-gnu-4.9.2 # gcc-config 2 # env-update && source /etc/profile # emerge --oneshot libtool # emerge --depclean (that removed the 4.8.3 gcc) # revdep-rebuild (no effect) # gcc-config -l [1] x86_64-pc-linux-gnu-4.8.3 [2] x86_64-pc-linux-gnu-4.9.2 * # ls -la /etc/env.d/gcc/ total 16 drwxr-xr-x 1 root root 166 Jan 13 13:12 . drwxr-xr-x 1 root root 276 Jan 13 13:12 .. -rw-r--r-- 1 root root 34 Jan 13 13:12 config-x86_64-pc-linux-gnu lrwxrwxrwx 1 root root 25 Jan 13 13:12 .NATIVE -> x86_64-pc-linux-gnu-4.9.2 -rw-r--r-- 1 root root 309 Jan 8 09:20 x86_64-pc-linux-gnu-4.8.3 -rw-r--r-- 1 root root 309 Jan 13 12:11 x86_64-pc-linux-gnu-4.9.2 # rm /etc/env.d/gcc/x86_64-pc-linux-gnu-4.8.3 # gcc-config -l [1] x86_64-pc-linux-gnu-4.9.2 * I assume that's not because I had used `emerge --depclean` instead of `emerge -C =sys-devel/gcc-4.8.3`
*** Bug 529608 has been marked as a duplicate of this bug. ***
this should be fixed by: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5fdfd991ec21885d4141440da97189f29dfa7b9 the bad news is that it won't help any existing installed versions or binpkgs because the pkg_* funcs are cached in the ebuild metadata, but it will help with all new builds moving forward. i guess lesson of the day is don't unmerge what you're using :).
