gcc-3.3.6-r1 doesn't compile anymore (at least in 2007.0 x86) because of changes in bison/yacc/glibc for that profile since it was marked stable (as shown in bug 159459), or most likely because it was only marked stable as a toolchain (system) compiler and not as an application compiler as required by the currently stable in x86 =app-emulation/qemu-0.9.0-r1 ebuild and reported in bug 194681. the problems had been reported in several other bugs before which were lumped together into bug 183766 with a request to drop support of the compiler instead of fixing the problems reported and which can be classified in at least 3 types : 1) ebuild scripting errors (as shown in bug 200016) 2) compilation errors because the code breaks due to changes in the build environment like bison or glibc (as shown in bug 200037, bug 200366, bug 200501, bug 200637 and others) 3) compilation errors because the -march or -mtune parameters used when trying to bootstrap are unknown (as shown in bug 191273, bug 183936, bug 180184, bug 198127) 4) other compilation problems which were closed as duplicates of the above cases and are therefore unknown because the reporters were told to shut up (as shown in bug 194395 and others) Reproducible: Always Steps to Reproduce: 1.emerge -Dv =sys-devel/gcc 2.file a bug 3. Actual Results: getting the report and the patches posted dupped into oblivion Expected Results: getting the report taking seriously and the patches committed so the problem gets fixed a working ebuild for gcc-3.3.6-r2 which includes patches for the problems reported in cases 1 and 2 is available from the following overlay : layman -f -o http://tapir.sajinet.com.pe/gentoo/layman.xml -a sajinet emerge -DNv =sys-devel/gcc-3.3.6-r2 and has been successfully build and tested using USE="-*" in Gentoo 2007.0 x86 with gcc 4.1.2 and -march=i686. if it fails to build for you might be because of case 3 which will be fixed soon but meanwhile try changing the -march or -mtune parameters to something more generic as i686 a workaround for this package.
case 1 was fixed in the last version of gcc-3.3.6-r1.ebuild (version 1.8) which was most likely pushed as part of a fix for bug 159459 but there is no mention to it in the ChangeLog for case 3 architectures that will need to be filtered as reported in the bugs are : athlon64, k8 and pentium-m but there might be others.
Created attachment 137589 [details] ebuild for gcc-3.3.6-r3 Adds replace-cpu-flags rules for x86 to alias all newer than 3.3.6 CPU-TYPEs and which should fix the last remaining case open. keyworded ~x86 for stabilization request (needed most likely only for x86) for a full list of changes, see the ChangeLog in the overlay. all required patches uploaded as part of bug 183766 but available from the overlay as well to simplify testing.
*** Bug 201386 has been marked as a duplicate of this bug. ***
*** Bug 201713 has been marked as a duplicate of this bug. ***
I pulled from http://tapir.sajinet.com.pe/gentoo/layman.xml and with one small update [1], I was able to compile and install gcc-3.3.6. I am building qemu right now. Thanks Carlo!! [1] Please update replace-cpu-flags for amd64/x86 nocona and native which point to i686. I emerged with gcc-4.2.2 on core 2 duo, 64-bit.
*** Bug 201732 has been marked as a duplicate of this bug. ***
And this bug turns into yet another dumpspace for ignored borkage, exactly like Bug 183766. toolchain - kindly drop the keywords from gcc-3.3* so that it stops getting pulled by the darned virtual/libstdc++ until it actually compiles.
again, go away. gcc-3.3.6 is being worked on.
(In reply to comment #8) > again, go away. gcc-3.3.6 is being worked on. Sigh, nice attitude dude... Why don't you drop the keywords from useless broken ebuilds? You like us getted flooded by these tons of duplicates, like pissed off users, or what exactly is the purpose of this? Why are you wasting other people's time w/ known-to-be-broken stuff?
please use this pseudo script for anything further: if (username == jakub && asssigne == toolchain) ; else post comment; i'll use something similar on my side. thanks!
What I don't understand is why in hell we're still pulling it in on x86 arch? Didn't 3.4 change the API/ABI significantly towards what gcc4 is now using? If so, why don't we start stripping an obsolete flag from x86 arch and hard masking packages that depend on it? Seems to be the most sensible way to solve the problem as it indicates either the upstream dev aren't interested in fixing the issue (might require major rewrite) or we start dropping them as no longer supported. In the case of Real Player, we need to either get on their ass about still needing the 3.3 toolchain when the 3.4 toolchain would at least have the same ABI on x86 or switch to the community helix player where we have the option to fix the problems as they come up. Personally, I'd rather we make the switch to the helix player in order to get the codec for mplayer, which I assume most of us use in prefernce to realplayer.
(In reply to comment #11) > What I don't understand is why in hell we're still pulling it in on x86 arch? Because libstdc++.so.5 is required by some binary cruft, and because with virtual/libstdc++ that's how portage behaves, see Bug 161953. Nothing like this would happen if gcc-3.3 ebuilds were masked pending a fix, or if the keywords were dropped from them at least. Both was refused by the maintainer so users must mask =sys-devel/gcc-3.3* themselves after having wasted their time on compiling something that's bound to fail. Enjoy.
*** Bug 201802 has been marked as a duplicate of this bug. ***
The attached ebuild doesn't work. * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/sys-devel/gcc/files/gcc-3.3-makelang.patch * ( gcc-3.3-makelang.patch ) There is no gcc-3.3-makelang.patch file in the FILESDIR in the portage tree.
Created attachment 138321 [details] The makelang patch; needed for installing the ebuild Downloaded from http://tapir.sajinet.com.pe/gentoo/portage/sys-devel/gcc/files/
Created attachment 138322 [details] Another necessary patch Taken from http://tapir.sajinet.com.pe/gentoo/portage/sys-devel/gcc/files/
Bug 201732 RealPlayer 10 now has a solution: Hard masked gcc-3.3.6 in /portage/profiles/package.mask Real Player 10 forced libstdc++3.3.6 (compatibility lib) usage Real Player 10 now fully functional due to compatibility library usage. Change Real Player Ebuild dependency to libstdc++3.3.6 instead of gcc-3.3.6
*** Bug 202216 has been marked as a duplicate of this bug. ***
*** Bug 202938 has been marked as a duplicate of this bug. ***
thanks, both patches now in 3.3.6-r1
