Follow-up Comment #4, bug #58979 (project make): Well, that's very good news (that it fails every time), in terms of tracking it down.
The fact that it fails every time for you and doesn't fail for anyone else (I should mention that at $DAYJOB I build software of significant size on CentOS 6.5, 6.6, 6.7 systems (as well as many other versions) with parallelism enabled with no problems) leads me to suspect something specific to your environment. The fist thing you should check for are any make warnings printed about the jobserver during your build. If you see that it can be an important clue. The way that the jobserver works is that it uses pipes shared between recursive invocations. These pipes are intended to be used only by GNU make. However, if some other process happens to read data from these pipes, or write data to these pipes, then it will corrupt the jobserver's idea of how many outstanding jobs exist. GNU make will close these pipes for any process it starts which it does not think is a make process. It uses the standard method for deciding this: either the variable $(MAKE) (or ${MAKE}) is referenced in the recipe, or the recipe is prefixed with a "+". This is the same algorithm that "make -n" uses to decide what to run and what to not run. So... one option would be to run "make -n" and see if you still get the hang behavior. Hopefully you will! If so, then you should examine carefully the programs that are invoked during "make -n" (the ones actually invoked, not just printed out!) and see if you can detect any of them doing weird things with file descriptors that they don't own or which were passed to them. Examine your recipes and look for ones that use the "+" prefix, and try removing that from those recipes and see if it helps. Examine recipes that invoke sub-makes using $(MAKE) or ${MAKE} and see if those variables appear as part of more complex recipe lines that might do something fancy with file descriptors; see if you can move the sub-make invocation into a separate line in the recipe so only the actual sub-make is invoked with "make -n" not other things. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58979> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/