I'm pretty sure that this was due to the gconftool race.  At least I can't replicate the failure after fixing gconf.bbclass with -j8 when I remove PARALLEL_MAKEINST.

Patch sent to oe-core.

Sadly I've just seen gthumb hang in compile so there is a problem with this recipe. This was with Ross' gconf changes applied. ps ax shows:

30934 pts/2    S+     0:00 /bin/sh /media/build1/poky/scripts/bitbake gthumb -c install
30952 pts/2    S+     0:01 python /media/build1/poky/bitbake/bin//bitbake gthumb -c install
30953 pts/2    Sl+    0:07 python /media/build1/poky/bitbake/bin//bitbake gthumb -c install
31048 pts/2    S      0:00 python /media/build1/poky/bitbake/bin//bitbake gthumb -c install
31049 pts/2    S      0:00 /bin/sh -e /media/build1/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gth
31050 pts/2    S      0:00 make -j 24
31053 pts/2    S      0:00 make all-recursive
31054 pts/2    S      0:00 /bin/bash -c fail= failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f in \? 
31185 pts/2    S      0:00 /bin/bash -c fail= failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f in \? 
31186 pts/2    S      0:00 make all
31187 pts/2    S      0:00 /bin/bash -c fail= failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f in \? 
31322 pts/2    S      0:00 /bin/bash -c fail= failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f in \? 
31323 pts/2    S      0:00 make all
31331 pts/2    S      0:00 make all-recursive
31332 pts/2    S      0:00 /bin/bash -c fail= failcom='exit 1'; \?for f in x $MAKEFLAGS; do \?  case $f in \? 
31345 pts/2    R      3:11 make all-am
31364 pts/1    S      0:00 bash
31429 pts/1    R+     0:00 ps ax

and the build log is pretty unhelpful. I'll try and figure this out further.

Hmpf.

I'll try with -j24 tomorrow.  I wonder what in the makefile is tripping up and spinning, from memory there wasn't anything complicated in it.

I'm pretty sure there is some bug in the glib-mkenum usage in gthumb's makefiles. Removing all the glib-mkenum usage makes things work. With it left as is, it wants to rexecute these targets multiple times per build and bombs out with anything other than "make". Even make -j 2 fails. It seems to be the fact they're listed in BUILD_SOURCES which means "make all" triggers them first and this interacts badly somehow with make all-recursive.

It seems these things are hard to get right and I noticed:

https://bugzilla.gnome.org/show_bug.cgi?id=654395
https://mail.gnome.org/archives/networkmanager-list/2012-February/msg00070.html

To confirm, the problem is in sections like:

enum-types.h: $(HEADER_FILES) $(GLIB_MKENUMS)
	$(AM_V_GEN)( $(GLIB_MKENUMS) \
		--fhead "#ifndef ENUM_TYPES_H\n#define ENUM_TYPES_H\n\n#include <glib-object.h>\n\nG_BEGIN_DECLS\n" \
		--fprod "/* enumerations from \"@filename@\" */\n" \
		--vhead "GType @enum_name@_get_type (void);\n#define GTH_TYPE_@ENUMSHORT@ (@enum_name@_get_type())\n" \
		--ftail "G_END_DECLS\n\n#endif /* ENUM_TYPES_H */" \
		$^> xgen-$(@F) \
	&& (cmp -s xgen-$(@F) enum-types.h || cp xgen-$(@F) enum-types.h ) \
	&& rm -f xgen-$(@F) )

where adding a "touch enum-types.h" to the end works around the problem. make is hanging waiting for the file to get updated but never sees the timestamp change it wants as far as I can tell.

and finally a reproducer note. Try "touch xxxx/glib-mkenum" where xxxx is the path within the sysroot (pretend glib was reinstalled), then force a recompile.

I totally have a patch for this.

Patch sent to oe-core.

This was merged earlier today.

(From OE-Core rev: dea6a0eb2bf06b3dc47e276a046d8dd828e47228)

Cannot reproduce with current master and `bitbake ghtumb`.

BB_VERSION        = "1.15.3"
TARGET_ARCH       = "i586"
TARGET_OS         = "linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.2+snapshot-20120830"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              
meta-yocto        = "master:bb0aab79e488a99cb1b43f72f0e8ddbe39d97519"