Bugzilla Bug 201035

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 an attachment (id=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 an attachment (id=138321) [details]
The makelang patch; needed for installing the ebuild

Downloaded from http://tapir.sajinet.com.pe/gentoo/portage/sys-devel/gcc/files/

Created an attachment (id=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