This morning I went from gcc-3.2.1 to gcc-3.2.1-r6. I have ACCEPT_KEYWORDS=~x86. The next package to emerge after gcc complained about: make: cc: Command not found Inside /usr/bin: lrwxr-xr-x 1 root root 3 Dec 16 11:19 cc -> gcc However, there was no gcc. My workaround for now was to create a symbolic link: ln -s /usr/i686-pc-linux-gnu/gcc-bin/3.2/gcc /usr/bin/gcc My portage is 2.0.45-r5. Anything else I need to tell about my system?
Never mind... I logged out and logged back in again and noticed that the PATH now contains a direct reference to /usr/i686-pc-linux-gnu/gcc-bin/3.2
Not so fast. Logging out and back in again lets me find /usr/i686-pc-linux-gnu/gcc-bin/3.2/gcc, however, I do have a orphan symbolic link left over (presumably from the old gcc-3.2.1.ebuild): lrwxr-xr-x 1 root root 3 Dec 16 11:19 /usr/bin/cc -> gcc Emerging procps, e.g., now still can't find cc because it doesn't exist. root@haroon root # emerge procps Calculating dependencies ...done! >>> emerge (1 of 1) sys-apps/procps-3.1.4 to / >>> md5 ;-) procps-3.1.4.tar.gz >>> Unpacking source... >>> Unpacking procps-3.1.4.tar.gz >>> Source unpacked. cc -MM -MG proc/alloc.c proc/compare.c proc/devname.c proc/ksym.c proc/output.c proc/pwcache.c proc/readproc.c proc/sig.c proc/status.c proc/sysinfo.c proc/version.c proc/whattime.c > proc/.depend /bin/sh: line 1: cc: command not found make: *** [proc/.depend] Error 127 So the fix, still seems to involve creating a symbolic link: cd /usr/i686-pc-linux-gnu/gcc-bin/3.2/ ln -s cc gcc and then everything is fine.
Everything is fine except that the missing /usr/bin/gcc causes "emerge --version" to display the following: Portage 2.0.45-r5 (default-x86-1.4, gcc-sh: line 1: /usr/bin/gcc: No such file or directory, glibc-2.3.1-r2)
Hi guys (wranglers), this should really have gone to me/carpaski ... Nick, the fix is to use `which gcc` ....
Same here... This killed my system. :( emerge --version Portage 2.0.45-r5 (default-x86-1.4, gcc-sh: line 1: /usr/bin/gcc: No such file or directory, glibc-2.3.1-r2)
Hello, its not in /usr/bin ! ---------- nosferatu root # which gcc /usr/i686-pc-linux-gnu/gcc-bin/3.2/gcc nosferatu root # ---------- Do the following: # env-update; source /etc/profile; hash -r Then 'gcc --version' and whatever should work. 'emerge --version' will fail, as portage look for gcc in /usr/bin. Anyhow, for portage the change of location of gcc is transparent .. its only if you havent logged out and back in, or sourced /etc/profile for the current bash/whatever session that gcc is 'missing'. Nick .. can we fix portage, or do you want me to look into it ?
seemant said to copy /usr/portage/sys-devel/gcc/files/cc and cpp to /usr/bin/cc and /lib/cpp which I did... is that wrong?
Carp Oh and as far as the portage fix, line 63 of emerge just needs to be changed from /usr/bin/gcc to `which gcc` and it's all good. :)
Erm, I would like to ask, if I may, why the binaries aren't put in /usr/bin anymore?
I just symlinked everything in /usr/i686-pc-linux-gnu/gcc-bin/3.2/ to /usr/bin, and everything seems to work.
comment #9 the new schema allows for multiple versions of gcc to be installed ... you can have 2.95.3 and 3.2.1, and you can have versions for x86/alpha/ppc/etc... this allows for cross-compiling and all that comment #7 yes, you should use gcc-config to setup the variables in your environment (use gcc-config then run env-update and then source /etc/profile) comment #10 that's really ugly/bad ... it wont work well with upgrading to newer versions
Ditto Vapier, thanks for explaining.
This maybe an oversight or maybe I'm not understanding something correctly, but using `which gcc` may (and actually doesn't) work if you emerge system (progressing from stage2 to stage3) with ACCEPT_KEYWORDS=~x86 set. Using `which gcc` will fail because which-2.14 is one of the last packages that gets installed, thusly gcc is not found. I can certainly emerge system before setting ACCEPT_KEYWORDS and then set the keywords back to ~x86 and update world, but if this version of gcc ever becomes stable this issue is going to bite people. Perhaps gcc-config or gcc need to have which in DEPEND? Just a thought. Besides this issue, after gcc is installed I can't find any trace of cc anywhere -- no symlink is created. Again, this is on a fresh system that just finished bootstrapping and starting to emerge system (current package is db-3.2.9-r1: * Building db_dump185... cc -c -O3 -march=pentium3 -pipe -D_GNU_SOURCE -I/usr/include/db1 - I../dist/../include -D_REENTRANT ../dist/../db_dump185/db_dump185.c -fPIC - DPIC -o db_dump185.lo ./libtool: cc: command not found !!! ERROR: sys-libs/db-3.2.9-r1 failed. !!! Function src_compile, Line -47, Exitcode 1 !!! (no error message)
Check my mail to -user and -dev .. its due to the old gcc's pkg_postinst() borking /lib/cpp and /usr/bin/cc. As for the which issue ... if you start from stage1, which are already present, although not in the pkg database, and it works (tested about 8 full bootstrap and emerge systems here ... )
*** Bug 12302 has been marked as a duplicate of this bug. ***
How strange. I guess it's my dumb luck...just bootstrapped and started emerging system (it died after failing to retreive sed-4.0.4, but thats a different story): cdimage / # which bash: which: command not found cdimage / # ls -1 /usr/bin | grep -i ^w wc wget whatis whereis who whoami write
This seems to be the topic of #gentoo to fix the problem... however the solution provided by these guys doesn't seem like the correct one as Azarah has said it's env-update; source /etc/profile; hash -r http://forums.gentoo.org/viewtopic.php?t=26686&postdays=0&postorder=asc&start=0
Hello (ladies and?) gentlemen. Doug was so kind to point out the bug 12250 submitted by me recently is most likely a dupe of this one. You may want to confirm this, just in case, but as I am reading 12246, I am amlmost certain that it mentions exactly the problems I ran in. Now if I had only posted my report five bug reports earlier, then I would have been the first. ;)
*** Bug 12250 has been marked as a duplicate of this bug. ***
*** Bug 12387 has been marked as a duplicate of this bug. ***
I know Vapier marked my other bug as a dup of this. But it's really not. Because the problem with this bug is that the PATH is updated to point to the currently selected GCC and old versions of GCC don't get uninstalled properly so the PATH calling scheme gets messed up. However removing the old GCC references and running env-update; source /etc/profile; hash -r to repair the current GCC PATH fixes everyones problem. The problem with http://bugs.gentoo.org/show_bug.cgi?id=12387 is the fact that there is no cc in in the actual GCC binary directory. There needs to be a symbolic link in each GCC's binary directory to the gcc binary because there is a global cc symbolic link which is now invalidated by this PATH stuff.
This change breaks dev-util/colorgcc. It seems that the colorgcc scripts are hard-coded to look for gcc in /usr/bin. $compilerPaths{"gcc"} = "/usr/bin/gcc"; $compilerPaths{"g++"} = "/usr/bin/g++"; $compilerPaths{"cc"} = "/usr/bin/cc"; $compilerPaths{"c++"} = "/usr/bin/c++";
In Response to Comment #22: This would mean that colorgcc is not compatible with ccache either. colorgcc should really set those vars with `which gcc` and `which g++`
Doug: Basically -r6 provide /lib/cpp and /usr/bin/cc as shell scripts, and yes, it does work fine. The problem comes into that the old gcc's pkg_postrm(), removes this scripts, and add broken symlinks. This is also the cause for my portage 'fix' that borked things. Thus, to fix: 1) emerge the latest gcc-config. 2) emerge and use portage-2.0.46 (its fixed, and wont bork your system) 3) follow my instructions to -dev and -user As for colorgcc, file a bug for me, ill get to fixing it somewhere ...
Ok, the colorgcc issue was filed as a bug: http://bugs.gentoo.org/show_bug.cgi?id=12689 This is fixed. Closing this, as it should be fixed now.
