Hello, I use GCC 4.1.1 and xmoto-0.2.1 fails if I compile it with MAKEOPTS="-j2" or higher, I must use MAKEOPTS="-j1" or it fails to build Making all in extra make[1]: Entering directory `/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1/extra' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1/extra' make[1]: Entering directory `/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1' !!! ERROR: games-sports/xmoto-0.2.1 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile ebuild.sh, line 1255: Called games_src_compile games.eclass, line 136: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant.
Created attachment 97080 [details] xmoto-0.2.1.ebuild - Forces MAKEOPTS="-j1"
Created attachment 97081 [details, diff] xmoto-0.2.1.diff I confirm this problem and the solution, on x86 (athlon-xp) with gcc-3.4.5-r1 (old, I know). Here's the required patch.
That's not the solution, just a workaround.
(In reply to comment #3) > That's not the solution, just a workaround. Yup. A workaround which fixes a problem. Something which fixes a problem is a solution. You don't just keep the problem going until you've come up with the *perfect* "solution", because that's stupid, when there are reasonable measures in-between. Are you saying that this solution is reasonable or unreasonable?
ebuilds aren't to touch MAKEOPTS
(In reply to comment #4) > (In reply to comment #3) > > That's not the solution, just a workaround. > > Yup. A workaround which fixes a problem. Something which fixes a problem is a > solution. You don't just keep the problem going until you've come up with the > *perfect* "solution", because that's stupid, when there are reasonable measures > in-between. Are you saying that this solution is reasonable or unreasonable? I'm saying workarounds avoid problems not fix them.
(In reply to comment #5) > ebuilds aren't to touch MAKEOPTS There's lots that *do* "touch MAKEOPTS", from my quick grep query. Should I raise a separate bug with a list of them? Is it better to use "emake -j1" in the ebuild? Thanks for explaining *nothing*. If you could provide a *reason*, then that would help people like me (who want to contribute, and *have* contributed) a hell of a lot to understand what on Earth is going on here. Rather than just stating facts as if they are obvious, when they are totally non-obvious.
sorry, I had parallel make disabled and did not notice this while bumping :( I have worked around it with emake -j1. This of course is no solution. The solution is to patch the makefiles so that they properly work in parallel. no idea either why makeopts is evil, mr_bones? Will see what I can do about the makefiles now.
upstream moved the xmoto target to the subdir but still wants the result in the top directory. But the rule here is broken xmoto: src/xmoto ln -sf src/xmoto xmoto make: *** No rule to make target `src/xmoto'. Stop. but cd src; make xmoto works. Since I do not know another way to do it I will probably ask upstream to revert the change. Any better ideas?
Comment on attachment 97081 [details, diff] xmoto-0.2.1.diff because other package maintainers do such garbage is no excuse at any rate; fix the package properly, dont be lazy and force -j1
(In reply to comment #10) > fix the package properly Yeah, great. Until the "ideal" fix, are you going to ignore the "pragmatic" fix of "-j1", for some strange reason of idealism over reality?
(In reply to comment #11) > (In reply to comment #10) > > fix the package properly > > Yeah, great. Until the "ideal" fix, are you going to ignore the "pragmatic" fix > of "-j1", for some strange reason of idealism over reality? > "I have worked around it with emake -j1."
workarounds have a tendency to become permanent fixes fix it once; dont work around it many times
I mailed upstream about this. They are informed of the issue. Will keep you updated.
no longer fails in 0.2.4
