Summary: | switch to gcc-3.4.4-r1 happens automatically | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Kundrát (RETIRED) <jkt> |
Component: | [OLD] GCC Porting | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | amne, henrik |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | gcc-upgrading-guide.xml.patch |
Description
Jan Kundrát (RETIRED)
2005-12-03 04:16:16 UTC
Same thing happened here. Happened here also Hmm, it seems that this issue affects the `emerge -e system` part of our guide. After installing "new" gcc version the toolchain eclass switches to the newly installed compiler (where "new" could mean older version as well - if you have 3.4.4-r1 installed and re-emerge 3.3.6 afterwards, it would switch as well). I've verified this by `quickpkg =gcc-3.3.6` followed by `emerge -avK =gcc-3.3.6`. It said it switched to the 3.3.6 and `gcc-config` displayed the same. I'm not sure if it would affect stuff in one emerge pass, though - would portage use the newly-switched-to evrsion of the compiler? And I'm not affected by some orphaned /etc/env.d/gcc/config*: slon ~ # l /etc/env.d/gcc/ total 52K drwxr-xr-x 2 root root 4.0K Dec 3 12:09 . drwxr-xr-x 5 root root 4.0K Dec 3 14:07 .. -rw-r--r-- 1 root root 32 Dec 3 14:50 config -rw-r--r-- 1 root root 296 Dec 3 14:49 i686-pc-linux-gnu-3.3.6 -rw-r--r-- 1 root root 364 Dec 3 14:49 i686-pc-linux-gnu-3.3.6-hardened -rw-r--r-- 1 root root 369 Dec 3 14:49 i686-pc-linux-gnu-3.3.6-hardenednopie -rw-r--r-- 1 root root 372 Dec 3 14:49 i686-pc-linux-gnu-3.3.6-hardenednopiessp -rw-r--r-- 1 root root 369 Dec 3 14:49 i686-pc-linux-gnu-3.3.6-hardenednossp -rw-r--r-- 1 root root 292 Dec 3 12:09 i686-pc-linux-gnu-3.4.4 -rw-r--r-- 1 root root 356 Dec 3 12:09 i686-pc-linux-gnu-3.4.4-hardened -rw-r--r-- 1 root root 361 Dec 3 12:09 i686-pc-linux-gnu-3.4.4-hardenednopie -rw-r--r-- 1 root root 364 Dec 3 12:09 i686-pc-linux-gnu-3.4.4-hardenednopiessp -rw-r--r-- 1 root root 361 Dec 3 12:09 i686-pc-linux-gnu-3.4.4-hardenednossp So, I think that moving `emerge -1 libstdc++v3` *before* `emerge -e system` would fix that. Somebody should update the doc then. Created attachment 73984 [details, diff]
gcc-upgrading-guide.xml.patch
What about this?
(In reply to comment #5) > What about this? In CVS. However, the announcements still say that the compiler won't be switched automagically, and that is not true :-(. Another note - solar suggested adding "older" to the "To provide compatibility with binary C++ applications ...". This makes no sense that it updates to it. I'm almost positive it did not do so on my machines. Could someone look over the logic in should_we_gcc_config() in toolchain.eclass? It should not be upgrading to the new compiler since that could introduce some interesting results. fixed in cvs |