Summary: | games-board/qgo-1.5.4 fails building with sys-devel/gcc-4.3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | [OLD] GCC Porting | Assignee: | Gentoo Games <games> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 198121 | ||
Attachments: |
build.log
possible patch possible patch |
Description
Dennis Schridde
2008-03-12 13:29:49 UTC
Created attachment 145895 [details]
build.log
see bug #198121: "Until 4.3.0 is released, filing bugs without patches enclosed is strongly discouraged and will very likely just end up being RESOLVED WONTFIX." Hmm... To which bug shall I then attach any patches to if they get closed before I come to attaching a patch? I'm currently rebuilding my whole system to figure out (kinda contribution like) which packages will break, so that you can at least have an idea of how much damage an update will cause. (I assume you don't build 100k+something packages at home just for testing, do you?) Do you believe me that it might take me a few days (I've got other stuff to do, too) to patch every package that is broken? And how do you know which packages break by the bump, if you close them all? This surely looks better on the stats, but it doesn't make much sense to me... The implication is that you'll wait to file the bug until you actually *have* a patch instead of just talking about one. I wish you a lot of fun bumping packages and noticing afterwards what they broke. :) PS: Closing eyes doesn't make bugs go away. I guess it just needs to include iostream instead of iostream.h? Created attachment 145985 [details, diff]
possible patch
This patch seems to do the trick in a non-portage compile.
The iostream in tree.cpp was not needed. (Patch removes it.)
The one in matrix.cpp was only needed if NO_DEBUG was not defined. (Patch fixes it anyway, since the KDE code in ./admin/acinclude.m4.in seems to be ignored or overridden (possibly broken configure.in?).)
Created attachment 145986 [details, diff]
possible patch
This patch seems to do the trick in a non-portage compile.
The iostream in tree.cpp was not needed. (Patch removes it.)
The one in matrix.cpp was only needed if NO_DEBUG was not defined. (Patch fixes it anyway, since the KDE code in ./admin/acinclude.m4.in seems to be ignored or overridden (possibly broken configure.in?).)
I currently can not test this with portage, since --empty --world is still running and failing regularly. Thus my --resume would be broken by a parallel merge. (Does someone know how to keep the "todo" for more than one merge?)
reopening, now that there is a working patch. Was this patch sent upstream? Upstream is working on qgo-2. I didn't sent the patch to them. Tracked upstream as http://sourceforge.net/tracker/index.php?func=detail&aid=1919484&group_id=41645&atid=430966 Any chance of inclusion into Portage? Fixed, thanks. |