GCC 3.3.3 is slated for release on 31 January 2004. There is a bug detailed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13134 As stated, it completely breaks glibc compilation. This is a major regression, and I think it would be worth adding an entry to package.mask as follows: # GCC 3.3.3 will, when released, break glibc compilation - masking until # confirmed safe to ensure nobody tries to bootstrap with it. If you unmask # this, recompiling glibc will cause a segfaulting linker. DO NOT UNMASK. >=sys-devel/gcc-3.3.3 There are already a couple of ebuilds for GCC 3.3.3 with a CVS snapshot update knocking about on the forums. People are complaining that this causes the newly compiled glibc linker to segfault. I know that this isn't usual Gentoo policy, but I do think that this would be very much worthwhile.
gcc-3.3.3 isnt in portage like you said, it isnt released yet so putting a mask into package.mask for something that isnt in portage doesnt make sense to me ... and who is to say that they wont fix it in 3.3.3 final ? :) if you'd like to see a package.mask entry to try to keep people from merging a 3.3.3 cvs snapshot they found on the forums, then i'd say 'its your own damned fault, you fix it' :)
Fair enough - it should, however, be remembered that there is currently no valid test for this bug yet in the testing suite, so the final 3.3.3 release may well contain this, or a related, bug. Whether a working test will find its way into the testing suite before 31/01/2004 or not is highly debatable. I will make sure that I test this towards the end of January against 3.3.3-cvs to ensure that our current stable and testing glibc's compile and work, and if they don't will reopen this bug. Closing for now.
we dont exactly go blindly adding gcc/glibc ebuilds to portage w/out emerging them first :) but it would be appreciated if you kept a thumb on this and later poked this bug when 3.3.3 nears release date
Don't forget schedules aren't always kept. gcc-3.3.2 got delayed a few times, likely gcc-3.3.3 won't meet its projected release date either, so this gives us additonal time if necessary.
This bug has been fixed in both 3.3.3 and 3.4.0. Leaving as RESOLVED INVALID.
