Summary: | GCC 3.3.3 must be hard masked now to ensure that glibc does not break | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Moss (RETIRED) <robmoss> |
Component: | New packages | Assignee: | Please assign to toolchain <gcc-porting> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | vapier |
Priority: | High | ||
Version: | 1.4 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Robert Moss (RETIRED)
![]() 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. |