This is causing a nonsensical behaviour of virtual/libstdc++ (see Bug 161953), is unsupported and generally noone should use this. (If you dislike this suggestion, there's an alternative one in Bug 161953, Comment #4)
What's wrong with removing gcc-3.3 from virtual/libstdc++ entirely?
(In reply to comment #1) > What's wrong with removing gcc-3.3 from virtual/libstdc++ entirely? Forcing completely unneeded sys-libs/libstdc++-v3 for people who already have it?
Well ping, getting tired of bugs about non-compiling gcc-3.3...
*** Bug 191273 has been marked as a duplicate of this bug. ***
*** Bug 183936 has been marked as a duplicate of this bug. ***
*** Bug 180184 has been marked as a duplicate of this bug. ***
*** Bug 194395 has been marked as a duplicate of this bug. ***
*** Bug 198127 has been marked as a duplicate of this bug. ***
*** Bug 200016 has been marked as a duplicate of this bug. ***
*** Bug 200037 has been marked as a duplicate of this bug. ***
=sys-devel/gcc-3.3 is the only stable compiler for x86 that can compile >=app-emulation/qemu-0.9.0 as shown by bug 194681
(In reply to comment #12) > =sys-devel/gcc-3.3 is the only stable compiler for x86 that can compile > >=app-emulation/qemu-0.9.0 as shown by bug 194681 QEMU's upstream long-lasting failure to provide non-broken code that'd compile w/ gcc-4 is completely outside the scope of this bug.
*** Bug 200366 has been marked as a duplicate of this bug. ***
*** Bug 200501 has been marked as a duplicate of this bug. ***
Ping! Can someone finally mask the unusable thing?
(In reply to comment #16) > Ping! Can someone finally mask the unusable thing? a working ebuild for gcc-3.3.6-r2 which includes patches for the problems reported in bug 200016, bug 200037, bug 200366 and bug 200501 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 an unsupported -march (like k8), so try changing that to something more generic as a workaround at least for this package.
(In reply to comment #17) > a working ebuild for gcc-3.3.6-r2 which includes patches for the problems > reported in bug 200016, bug 200037, bug 200366 and bug 200501 is available from > the following overlay : Awesome. I was going to work on this tonight. Could you attach the patches here for those specific issues (so I don't have to go through your ebuild and figure out what you changed? Thanks
Created attachment 137187 [details, diff] fixes to Make-lang.in to avoid parameter mangling adds an extra space before the "\" line concatenation to avoid parameter mangling
Created attachment 137189 [details, diff] fix definition for stpcpy in glibc-2.6 requires __DEFINE_GNU to enable GNU extensions and stpcpy as used by the bison parse rules
Created attachment 137191 [details] ebuild for gcc-3.3.6-r2 based on gcc-3.3.6-r1 with the following changes : * fixes the use of obsolete is_uclibc call * removes commented out patch for some cleanup * marked ~amd64 but kept stable in x86 (as this is the configuration that is needed for qemu which can't use other compilers in that arch)
*** Bug 200637 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 159459 ***
*** Bug 201011 has been marked as a duplicate of this bug. ***
Which part of this thing miserably fails to compile due to tons of issues is unclear here? :(
Carlo, Sorry to be a pain, but could you open up a new bug for gcc-3.3.6-r2 so we can more easily track it. Thanks
i'm not going to package mask 3.3.6
(In reply to comment #27) > i'm not going to package mask 3.3.6 So you will fix all the issues mentioned here and on the other bugs duplicated here? Or what's exactly the plan?
(In reply to comment #26) > Carlo, > > Sorry to be a pain, but could you open up a new bug for gcc-3.3.6-r2 so we can > more easily track it. filed bug 201035, case 1 was solved in the last update for gcc-3.3.6-r1 eventhough there is no comment about it on the ChangeLog.
*** Bug 201989 has been marked as a duplicate of this bug. ***
(In reply to comment #27) > i'm not going to package mask 3.3.6 > Reasoning? To force some innocent users to be your test piggies!? It's - afaik needlessly - very inconvenient for our user base. At least on x86 and amd64 every version below GCC 4 should be masked.
What about Hardened then?
