| View previous topic :: View next topic |
| Author |
Message |
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
 Posted: Thu Jun 23, 2005 8:45 am Post subject: GCC-3.4.4 needs GCC-3.3.5 !?! [SOLVED] |
 |
|
EDIT: I've changed the title of this thread from "Stage1: gcc-config switches profiles by itself" to what you see now, as my efforts to resolve the matter have moved the emphasis somewhat. If the new title drew your attention to the thread, please persevere through the opening posts, coz i need all the help i can get! 
Here is my initial post on this matter, pasted in from another thread for better continuity | taipan67 wrote: | After bootstrapping, when i ran
...i noticed that the environment had already switched to the newly installed gcc-3.4.4 by itself... Anyway, progressing on to
...highlighted the fact that i was about to re-emerge gcc-3.4.4, & immediately afterward, emerge gcc-3.3.6 as it supplanted 3.3.5 in the stable branch of portage. This caused me to worry that this 'auto-switching' might occur again, near the start of the system-build, & thus give me a system built with gcc-3.3.6 & not 3.4.4 as required... 
These fears appear to have been founded... After the emergence of gcc-3.3.6 & the removal of 3.3.5 came linux-headers, then glibc... Here's a snippet from the 3rd page out of 1187 pages of /var/log/portage/2245-glibc-2.3.5.log | Code: | | checking version of i686-pc-linux-gnu-gcc... 3.3.6, ok |
So i thought i'd switch compilers back to 3.4.4 & 'prune' the unneeded one (as per the tutorial) & 'emerge -e system' again - after all, i was going to rebuild anyway. The problem is that i can't get rid of the one i don't want!!! | Code: | emerge -Pp gcc
>>> These are the packages that I would unmerge:
sys-devel/gcc
selected: 3.4.4
protected: 3.3.6
omitted: none
>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed. |
Other than that, the only problem i had was that sys-libs/db wouldn't recognise the -fvisibility-inlines-hidden flag, so it was removed before an 'emerge --resume'... And that's in spite of doing everything humanly possible to fill the system with rice... | Code: | emerge info
Portage 2.0.51.22-r1 (!/usr/local/portage/profile, gcc-3.4.4, glibc-2.3.5-r0, 2.6.10-nitro4-GUI i686)
=================================================================
System uname: 2.6.10-nitro4-GUI i686 AMD Athlon(TM) XP 2500+
Gentoo Base System version 1.6.12
dev-lang/python: 2.3.4-r1, 2.4.1-r1
sys-apps/sandbox: 1.2.9
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils: 2.16.1
sys-devel/libtool: 1.5.18
virtual/os-headers: 2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=athlon-xp -fforce-addr -ftracer -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
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="-O3 -march=athlon-xp -fforce-addr -ftracer -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -s"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow X alsa apm arts avi berkdb bitmap-fonts bzip2 crypt cups emboss encode foomaticdb fortran gdbm gif gnome gpm gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod mmx motif mp3 mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell sse ssl tcpd truetype truetype-fonts type1-fonts xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS, MAKEOPTS |
...and yes, i am using reiser4 as well (hence the kernel). 
All that being said, insane FLAGS aren't going to be responsible for this, surely? Any suggestions on how to 'emerge -e system' without gcc-3.3.6, so it will all get built by 3.4.4? |
I don't think the FLAGS are to blame, because i used default ones for the bootstrap, as illustrated by my /etc/make.conf | Code: | CHOST="i686-pc-linux-gnu"
# FLAGS for gcc-3.3.* - comment out after bootstrap
#CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
#CXXFLAGS="${CFLAGS}"
# FLAGS for gcc-3.4.* - uncomment after bootstrap
CFLAGS="-O3 -march=athlon-xp -fforce-addr -ftracer -fomit-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -s"
PORTDIR_OVERLAY=/usr/local/portage
PORT_LOGDIR=/var/log/portage
ACCEPT_KEYWORDS="~x86"
USE="3dnow bzip2 mmx nptl sse" |
So my question is:- Does gcc-config now change the compiler being used automatically, as soon as a different one is installed, even if it's a downgrade... 
EDIT: This occurred using both gcc-config-1.3.11-r3 & whichever one comes with the stage1-x86-2005.0.tar.bz2 tarball (unless 'bootstrap' replaces the latter with the former... ).
_________________
"Anyone who goes to see a psychiatrist should have their head examined!"
Last edited by taipan67 on Sun Jun 26, 2005 3:15 pm; edited 6 times in total |
|
| Back to top |
|
 |
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Thu Jun 23, 2005 1:40 pm Post subject: |
|
|
I've received a response on another thread that looks promising... | hielvc wrote: | | From what I can tell this a flaw in the logic of gcc-config. It has a habit of switching to the last gcc version built. So if you made gcc-3.4.4 it switched to that, then you updated, gcc-3.3.4 to gcc-3.3.6 and it switched to that..To stick with gcc-3.4.4 do this " echo "<=/sys-devel/gcc-3.3*" >> /etc/portage/package.mask " then try a "emerge gcc -uDp " to check. See "man portage" for more info. Then use my script, see tag, and if you have any questions about this ask them on that thread. |
I'm presently reading up on the script mentioned before trying this solution - for anyone interested, it can be found here.
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
Specialized
Apprentice
Joined: 11 Jan 2005
Posts: 264
|
| Posted: Fri Jun 24, 2005 10:34 am Post subject: |
|
|
I haven't pruned the gcc-3.3.* .
Another possibilty to stick with the gcc-3.4.4 is to add this to your /etc/portage/package.keywords:
| Code: | sys-devel/gcc ~x86
sys-libs/glibc ~x86
sys-libs/libstdc++-v3 ~x86
sys-devel/gcc-config ~x86
|
Then with emerge -e system the gcc-3.4.4 will be ermerged and gcc-config switches from gcc-3.4.4 to gcc-3.4.4.
But you need to compile the gcc-3.4.4 with gcc-3.3.* first and the do the emerge -e system stuff. |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Fri Jun 24, 2005 1:13 pm Post subject: |
|
|
Cheers Specialized!
I've re-started with a Stage 3 tarball, & am presently awaiting a response to a post i've placed on hielvc's thread before beginning the toolchain rebuild. Once that's done, i'll see what 'emerge -epv system' throws up, & possibly mask gcc-3.3.*, if necessary... (I'm also doing it without syncing, so i have the same portage-snapshot as before - 20050620)
At least it will satisfy my curiosity about whether or not the previous problem was unique to my installation method... 
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Fri Jun 24, 2005 3:18 pm Post subject: |
|
|
Before reformatting the partition being used for these builds, i saved the source tarballs in order to cut the download time for this attempt, & running | Code: | | emerge -pv gcc-config glibc binutils libstdc++-v3 gcc |
...as per the Stage 1/3 Guide, has highlighted the fact that the tarball or tarballs required by 'libstdc++-v3' weren't previously downloaded, even though i got right through an 'emerge -e system'. 
A root through the portage directory has unearthed a couple of references that i need help to interpret - these are from 'sys-devel/gcc-3.4.4.ebuild' | Code: | PDEPEND="sys-devel/gcc-config
!nocxx? ( !mips? ( !ia64? ( !elibc_uclibc? ( !build? ( || ( sys-libs/libstdc++-v3 =sys-devel/gcc-3.3* ) ) ) ) ) )" |
...from line 72, & | Code: | if is_multilib ; then
sed -i -e '/GLIBCXX_IS_NATIVE=/s:false:true:' libstdc++-v3/configure || die
fi |
...from line 128.
That 2nd extract doesn't appear to be in 'gcc-3.4.3-20050110-r2.ebuild', & the 1st is notably different | Code: | PDEPEND="sys-devel/gcc-config
!nocxx? ( !mips? ( !ia64? ( !elibc_uclibc? ( !build? ( sys-libs/libstdc++-v3 ) ) ) ) )" |
To my extremely limited understanding, the inclusion of 'libstdc++-v3' & quite possibly the 'gcc-3.3.*'-upgrade are dependant on USE-flags, which in my case were defaults... Does anyone have any insights they can share on this?
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
slycordinator
Veteran
Joined: 31 Jan 2004
Posts: 3015
Location: Houston, TX
|
| Posted: Fri Jun 24, 2005 7:38 pm Post subject: |
|
|
| taipan67 wrote: | Before reformatting the partition being used for these builds, i saved the source tarballs in order to cut the download time for this attempt, & running | Code: | | emerge -pv gcc-config glibc binutils libstdc++-v3 gcc |
...as per the Stage 1/3 Guide, has highlighted the fact that the tarball or tarballs required by 'libstdc++-v3' weren't previously downloaded, even though i got right through an 'emerge -e system'. |
That's because libstdc++-v3 isn't part of the system profile. It used to be if you tried to install gcc, libstdc++-v3 would get installed afterwards automatically (assuming it wasn't already installed). Kind of a "post-dependency."
With gcc-3.4.4 that no longer happens. |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Fri Jun 24, 2005 10:21 pm Post subject: |
|
|
| slycordinator wrote: | That's because libstdc++-v3 isn't part of the system profile. It used to be if you tried to install gcc, libstdc++-v3 would get installed afterwards automatically (assuming it wasn't already installed). Kind of a "post-dependency."
With gcc-3.4.4 that no longer happens. |
Cheers, that's what i got told elsewhere, too. I'm not so sure, though, & before anyone starts reaching for their molotov's, i'll try to explain why...
I've still got my Stage 3 install waiting patiently to be rebuilt, but i've been running lots of 'pretend' builds on it, using conventional 'emerge' commands & also hielvc's two scripts, 'sys-build.sh' & 'emwrap.sh'. The syntax of each was:- "emerge system -ep", "sys-build.sh -p", & "emwrap.sh -sebp", respectively. In each scenario, 'emerge' & 'sys-build.sh' produced identical results, right down to the build-order as far as i could tell. Here are the results:-
Scenario 1 (testing-branch unmasked globally in /etc/make.conf)
'emwrap.sh' excluded both libstdc++-v3 & gcc-3.3.6; the others still included gcc-3.3.6.
Scenario 2 (testing-branch unmasked selectively for the toolchain components in /etc/portage/package.keywords)
'emwrap.sh' excludes both, again; the others include gcc-3.3.5.20050130-r1
Scenario's 3 & 4 (as above, but with "<sys-devel/gcc-3.4.3-r1" in /etc/portage/package.mask)
Build orders vary, but all include libstdc++-v3 & exclude any version of gcc-3.3.*
Final scenario's (as above, but after 'emerge sync') All results the same!
(I need a smoke!)
My tentative conclusion from all of this, is that gcc-3.4.4 still needs to have libstdc++-v3 present for backwards compatibility, or failing that a pre-3.4 version of gcc (hence that earlier snippet from it's ebuild). That would also explain why 3.3.6 was protected when i tried to 'prune' it, on the previous install. I suspect that the results from masking pre-3.4's are the ones that would result in a sane build, & that the first ones that included neither were an anomoly. I'd love it if i'm wrong & someone corrects me - that would mean one less package to build (repeatedly), & 23Mb less downloading to do. 
So if you should happen to see this, Bob, it looks like i would've been fine if only i'd used the line "emerge gcc-config glibc binutils libstdc++-v3 gcc" from your guide in the first place!!! Whatever Stage i used!!! (Sorry again for the aggravation  )
My plan now... Is to go to bed, actually... But after that, i think i'm gonna do the emerge-command just mentioned to upgrade the toolchain, adjust the optimisation settings in /etc/make.conf, then use 'emwrap.sh -seb' to rebuild it with itself, along with the rest of the system.
...And if that lot works, as well as marking the thread [SOLVED], i guess i should modify the title somewhat. Any suggestions...
EDIT: I think i am wrong - If all of the commands were issued with the '--emptytree' option, what difference would it make if i installed libstdc++-v3 beforehand? I guess pre-3.4 gcc's are getting masked again, unless anyone else can get their head round this...
_________________
"Anyone who goes to see a psychiatrist should have their head examined!"
Last edited by taipan67 on Sat Jun 25, 2005 3:48 pm; edited 2 times in total |
|
| Back to top |
|
|
slycordinator
Veteran
Joined: 31 Jan 2004
Posts: 3015
Location: Houston, TX
|
| Posted: Sat Jun 25, 2005 1:45 am Post subject: |
|
|
| taipan67 wrote: |
EDIT: I think i am wrong - If all of the commands were issued with the '--emptytree' option, what difference would it make if i installed libstdc++-v3 beforehand? I guess pre-3.4 gcc's are getting masked again, unless anyone else can get their head round this... |
libstdc++-v3 is not part of the system profile and isn't explicitly being installed by gcc either (like it used to be).
No amount of running "emerge --emptytree system" will install libstdc++-v3 as this command only causes the entire system profile (plus it's dependencies) to be reinstalled. Since this package isn't part of system and isn't a dependency of something in the system, it won't get installed. If you do "emerge libstdc++-v3" then libstdc++-v3 will be in your world file so doing "emerge --emptytree world" would work.
That's why it makes a difference. With older versions of gcc, libstdc++-v3 gets installed automatically. So then when you do "emerge -e system" libstdc++-v3 gets installed as well, not because it is part of "system" (it's not) but because the gcc ebuilds specified it to be installed. |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Sat Jun 25, 2005 7:43 am Post subject: |
|
|
| taipan67 wrote: | | ...In each scenario, 'emerge' & 'sys-build.sh' produced identical results, right down to the build-order as far as i could tell. |
That's because the script failed to use it's correct build-list. I'm hoping to hear back from hielvc on whether it's a bug, or (more likely) me doing something stoopid! (Go ahead, you know you want to...)
Until that's resolved, please only consider the relevance of the other two commands.
| slycordinator wrote: | | No amount of running "emerge --emptytree system" will install libstdc++-v3 as this command only causes the entire system profile (plus it's dependencies) to be reinstalled. Since this package isn't part of system and isn't a dependency of something in the system, it won't get installed. If you do "emerge libstdc++-v3" then libstdc++-v3 will be in your world file so doing "emerge --emptytree world" would work. |
Yep, i've got no argument with you on that...
Which is why i can't get past the notion that the ebuild-section posted previously | Code: | PDEPEND="sys-devel/gcc-config
!nocxx? ( !mips? ( !ia64? ( !elibc_uclibc? ( !build? ( || ( sys-libs/libstdc++-v3 =sys-devel/gcc-3.3* ) ) ) ) ) )" |
...is what's causing a pre-3.4 version of gcc to be installed after 3.4.4 if i don't mask against it, in which case i get libstdc++-v3 instead.
Can anybody translate that code-snippet for me, please? I know what DEPEND & RDEPEND refer to - never seen PDEPEND before. But with the default USE flags set, that string of conditions is true on my x86 (assuming '!' means 'NOT', as it does in C)...
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
Maedhros
Administrator
Joined: 14 Apr 2004
Posts: 5511
Location: Durham, UK
|
| Posted: Sat Jun 25, 2005 3:04 pm Post subject: |
|
|
Moved from Installing Gentoo to Portage & Programming.
_________________
No-one's more important than the earthworm. |
|
| Back to top |
|
|
canal
Apprentice
Joined: 28 Sep 2004
Posts: 203
|
| Posted: Sun Jun 26, 2005 6:54 am Post subject: |
|
|
| taipan67 wrote: | Which is why i can't get past the notion that the ebuild-section posted previously | Code: | PDEPEND="sys-devel/gcc-config
!nocxx? ( !mips? ( !ia64? ( !elibc_uclibc? ( !build? ( || ( sys-libs/libstdc++-v3 =sys-devel/gcc-3.3* ) ) ) ) ) )" |
...is what's causing a pre-3.4 version of gcc to be installed after 3.4.4 if i don't mask against it, in which case i get libstdc++-v3 instead.
|
It's only true if you already have pre-3.4 gcc installed.
| taipan67 wrote: |
Can anybody translate that code-snippet for me, please? I know what DEPEND & RDEPEND refer to - never seen PDEPEND before. But with the default USE flags set, that string of conditions is true on my x86 (assuming '!' means 'NOT', as it does in C)... |
PDEPEND is like RDEPEND but portage will only install requirements after main package is installed. Even if you are doing "emerge -e" portage will use current database to determine preferences. If you have "=sys-devel/gcc-3.3*" installed - then this is what will be reinstalled. If not - sys-libs/libstdc++-v3 will be used (it's first in line thus is preferred unless something other interfere with selection process). |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Sun Jun 26, 2005 8:33 am Post subject: |
|
|
| canal wrote: | | It's only true if you already have pre-3.4 gcc installed. |
Cheers canal! I like the sound of that, though it doesn't seem to have afflicted anybody else in this way...
I still have an unmolested Stage 3, waiting to be attacked, so i think what i'm gonna do now is | Code: | | emerge linux-headers glibc binutils gcc |
...then run some more tests, (possibly) including checking whether or not i'm allowed to prune gcc-3.3.5 this time...
Back in a few hours! 
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Sun Jun 26, 2005 9:12 am Post subject: |
|
|
Addition to my previous post | taipan67 wrote: | | ...though it doesn't seem to have afflicted anybody else in this way... |
Aaahh! The penny drops! | canal wrote: | | Even if you are doing "emerge -e" portage will use current database to determine preferences. |
That explains why Bob P's Stage 1/3 Method works so well - the current database has libstdc++-v3 in it!
EDIT: It would also mean that Stage 1 installs based on the current handbook can't use testing-branch versions of GCC (i think...)!
I should be able to confirm this by running the previously stated 'emerge' command without libstdc++-v3, & checking what 'emerge system -ep' outputs... Any bets on what i find?
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Sun Jun 26, 2005 10:04 am Post subject: |
|
|
I'm editing the thread-title again to something a little more attention-grabbing!  (Initial toolchain rebuild still in progress...)
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Sun Jun 26, 2005 3:14 pm Post subject: |
|
|
Okay then! Here are the results...
After running:- | Code: | emerge linux-headers glibc binutils gcc
# Optimising /etc/make.conf
# Switching profiles with 'gcc-config'
env-update && source /etc/profile |
...we get:- | Code: | gentoo / # emerge system -ep | grep gcc
[ebuild N ] sys-devel/gcc-config-1.3.11-r3
[ebuild N ] sys-devel/gcc-3.4.4
[ebuild N ] sys-devel/gcc-3.3.6
gentoo / # emerge system -ep | grep c++
gentoo / # |
...& with pre-3.4.* versions of gcc masked in /etc/portage/package.mask, we get:- | Code: | gentoo / # emerge system -ep | grep gcc
[ebuild N ] sys-devel/gcc-config-1.3.11-r3
[ebuild N ] sys-devel/gcc-3.4.4
gentoo / # emerge system -ep | grep c++
[ebuild N ] sys-libs/libstdc++-v3-3.3.4
gentoo / # |
...& just for the sake of completeness, after emerging 'libstdc++-v3' & not bothering to mask anything, we get:- | Code: | gentoo / # emerge system -ep | grep gcc
[ebuild N ] sys-devel/gcc-config-1.3.11-r3
[ebuild N ] sys-devel/gcc-3.4.4
gentoo / # emerge system -ep | grep c++
[ebuild N ] sys-libs/libstdc++-v3-3.3.4
gentoo / # |
(Bugger!!! I just realised that i forgot to test whether or not gcc-3.3.5 was prunable before emerging 'libstdc++-v3' - it is now, & my guess is that it wouldn't have been before, but that's not very scientific, is it? )
So there we have it, for anybody skipping straight to the conclusions:-
GCC-3.4.4 still needs some backward-compatibility with 3.3.* versions, if it has been installed on a system that already has history of it, & regardless of the '--emptytree' option. Which means all Gentoo users, doesn't it? (EDIT: For a much better explanation, see canal's following post...)
Many thanks to all who have contributed to this bumbling little odyssey, especially canal for that elusive piece of the jigsaw regarding '--emptytree'.
I'm off to rebuild my new toolchain with itself, precisely as detailed by Bob P's guide - coz now, i not only know that it works, i know why it works!
_________________
"Anyone who goes to see a psychiatrist should have their head examined!"
Last edited by taipan67 on Sun Jun 26, 2005 6:29 pm; edited 1 time in total |
|
| Back to top |
|
|
canal
Apprentice
Joined: 28 Sep 2004
Posts: 203
|
| Posted: Sun Jun 26, 2005 5:37 pm Post subject: |
|
|
| taipan67 wrote: | (Bugger!!! I just realised that i forgot to test whether or not gcc-3.3.5 was prunable before emerging 'libstdc++-v3' - it is now, & my guess is that it wouldn't have been before, but that's not very scientific, is it? )
|
Portage will happy remove it. And then you'll have HUGE problems. Why ? Python can not be used without libstdc++-v3 ! And so if you'll install gcc-3.4, then remove gcc-3.3 and then... portage will be broken and you'll spend two days trying to fix it.
| taipan67 wrote: |
So there we have it, for anybody skipping straight to the conclusions:-
GCC-3.4.4 still needs some backward-compatibility with 3.3.* versions, if it has been installed on a system that already has history of it, & regardless of the '--emptytree' option. Which means all Gentoo users, doesn't it?
|
gcc itself does not need any gcc-3.3.* version compatibility. But... portage does need such compatibility till python is recompiled! And some commercial programs need this as well. I've removed libstdc++-v3 package at some time (along with gcc 3.3.x) - and all worked just fine (when python is recompiled!). The only exceptions were RAR and some other commercial packages.
P.S. And yes: when I had system without both =gcc-3.3.* and libstdc++-v3 emerge pulled libstdc++-v3, not =gcc-3.3.* on upgrade (as expected). It's just impossible to use in upgrade process since portage will be broken. |
|
| Back to top |
|
|
taipan67
l33t
Joined: 04 Dec 2004
Posts: 789
Location: England (i'm told...)
|
| Posted: Sun Jun 26, 2005 6:19 pm Post subject: |
|
|
| canal wrote: | | gcc itself does not need any gcc-3.3.* version compatibility. But... portage does need such compatibility till python is recompiled! And some commercial programs need this as well. I've removed libstdc++-v3 package at some time (along with gcc 3.3.x) - and all worked just fine (when python is recompiled!). The only exceptions were RAR and some other commercial packages. |
Thanks for the clarification, canal. I had it straight in my head, but as usual couldn't explain myself well enough.
To correct my earlier post, i've only tested the 'prunability' of gcc-3.3.5, i haven't done it, yet, & won't, at least until i've emerged the rest of the system, as per 'The Guide' (toolchain re-rebuild still in progress...)
_________________
"Anyone who goes to see a psychiatrist should have their head examined!" |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
