No tengo una respuesta para este problema en concreto, pero puedo intentar darte una pista de lo que puede estar pasando:Dependencias faltantes en Makefiles.
Ejemplo:
target: a.bytecode b.bytecode
link a.bytecode b.bytecode -o target
a.bytecode: a.source
compile a.source -o a.bytecode
b.bytecode: b.source
compile b.source a.bytecode -o a.bytecode
Si llamas make target todo se compilará correctamente. Compilación de a.source se realiza (arbitrariamente, pero de manera determinista) primero. Luego compilación de b.source se realiza.
Pero si make -j2 target ambos compile Los comandos se ejecutarán en paralelo. Y realmente notará que las dependencias de su Makefile están rotas. La segunda compilación asume a.bytecode ya está compilado, pero no aparece en las dependencias. Por lo tanto, es probable que ocurra un error. La línea de dependencia correcta para b.bytecode debería ser:
b.bytecode: b.source a.bytecode
Volviendo a su problema, si no tiene suerte, es posible que un comando se cuelgue en un bucle de CPU al 100% debido a una dependencia faltante. Probablemente eso es lo que está sucediendo aquí, la dependencia faltante no pudo ser revelada por una compilación secuencial, pero sí ha sido revelada por su compilación paralela.
No sé cuánto tiempo ha tenido la máquina, pero mi primera recomendación sería probar una prueba de memoria y verificar que la memoria funciona correctamente. Sé que a menudo no es la memoria el problema, pero si lo es, es mejor eliminarlo como causa primero antes de intentar rastrear otros problemas probables.
Me doy cuenta de que esta es una pregunta muy antigua, pero aún aparece en la parte superior de los resultados de búsqueda, así que aquí está mi solución:
GNU make tiene un mecanismo de servidor de trabajos para garantizar que make y sus hijos recursivos no consuman más del número especificado de núcleos:http://make.mad-scientist.net/papers/jobserver-implementation/
Se basa en una tubería compartida por todos los procesos. Cada proceso que quiera bifurcar niños adicionales primero debe consumir tokens de la canalización y luego renunciar a ellos cuando haya terminado. Si un proceso secundario no devuelve los tokens que consumió, el make while de nivel superior se cuelga para siempre esperando que se devuelvan.
https://bugzilla.redhat.com/show_bug.cgi?id=654822
Encontré este error al compilar binutils con GNU make en mi caja de Solaris, donde "sed" no es GNU sed. Jugar con PATH para hacer que sed==gsed tenga prioridad sobre el sistema sed solucionó el problema. Sin embargo, no sé por qué sed estaba consumiendo tokens de la canalización.