Summary: | Emerge netpbm-10.31 fails to build in parallel | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | moesasji <henkjans_bagger> |
Component: | New packages | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | askwar, charlie, che, Martin.vGagern, matrixhax0r, meff, mkyral, ssuominen, ulrich.meyle |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 128495 | ||
Attachments: |
netpbm-10.32-parallel.patch
Patch to the netpbm-10.32.ebuild netpbm-10.32-parallel.patch v2 |
Description
moesasji
2005-12-24 23:21:43 UTC
emerge it with MAKEOPTS=-j1 to workaround the bug Changing to MAKEOPTS=j1 indeed makes that emerge finishes. Thanks for the suggestion. OK, commited to portage patch which should fix compile problems in parallel patch didnt fix the issue, just made it less prevalent netpbm-10.32 on amd64 displays the same behavior. *** Bug 124380 has been marked as a duplicate of this bug. *** Same error here for 10.32 ~x86. Couldn't -j1 opt be set directly into the ebuild? *** Bug 124396 has been marked as a duplicate of this bug. *** *** Bug 124423 has been marked as a duplicate of this bug. *** Same problem here, on ~x86. MAKEOPTS="-j1" fixed it. Also, just met 2 people on IRC with same problem. Should be in ebuild. IMO. *** Bug 124437 has been marked as a duplicate of this bug. *** *** Bug 124439 has been marked as a duplicate of this bug. *** The issue still exists in 10.32, as others have recently posted. Forcing a non-parallel make, via MAKEOPTS, fixed it. Please fix. you seem to be confused forcing MAKEOPTS to -j1 is not a fix, it's a hack (In reply to comment #14) > you seem to be confused > > forcing MAKEOPTS to -j1 is not a fix, it's a hack > Yes, ugly hack, but this I found in mplayer ebuild: # we run into problems if -jN > -j1 # see #86245 MAKEOPTS="${MAKEOPTS} -j1" just because other devs utilize hacks doesnt mean it's correct ;) Created attachment 80978 [details, diff]
netpbm-10.32-parallel.patch
This patch is not an adaptation of the netpbm-10.31-parallel.patch.
Instead I tried to track down the reason for the missing dep.
Main reason of course is some weird makefile design where makefiles from the inner directories execute rules in the root dir as well.
The dependency on inttypes_netpbm.h resultet from importinc and comes from Makefile.common which is included by different makefiles. The rule to provide this file is only present in the toplevel GNUmakefile, so the other files have trouble satisfying this rule. I went with the design of the rest of the files and added a rule to call the root makefile to provide this file.
I think I also fixed a bug in the difference between BUILDDIR and SRCDIR, but as those are the same on Gentoo builds I don't know for sure, nor do I particularly care. I'ts included in the patch, wether it would work (better) for different environments is for someone else to test.
So far I had one successful compile. I think I will try to compile it in a loop several times, but I'd be happy if others would test this as well.
Created attachment 80981 [details, diff] Patch to the netpbm-10.32.ebuild This patches the ebuild to include attachment #80978 [details, diff]. It also moves several configuration things from src_unpack to src_compile where they belong IMHO. And talking about hacks: I alway thought that the hack would usually be to provide an argument to emake as in "emake -j1". Modifying MAKEOPTS seems even worse than that. Hopefully we can do without a hack on this one soon. Created attachment 80995 [details, diff]
netpbm-10.32-parallel.patch v2
I still got errors every now and then. Fixed one, got another one, and decided this was no fun at all... :-(
Now I simply added a dep on importinc to the recursive calls for target all. So importinc (which combines all the troublemakers so far) is called before any serious compilation is done. This would be a problem if you were to compile only the contents of a single directory in a virgin source tree, but who would do this in parallel? For the whole tree, starting with the top level GNUmakefile, the deps should hopefully be correct now. At least I got 20 clean compiles in a row. :-)
In any case, perhaps autotooling the whole affair would be the best approach. Unfortunately I've never worked with autotools so far, so someone else is probably better in converting this whole thing.
Patch works for me too. I suppose this is good enough for now, added patch to cvs. Thanks! Please push it upstream. Folks: please reopen this bug if it is still a problem. *** Bug 124476 has been marked as a duplicate of this bug. *** |