Non ho una risposta a questo problema preciso, ma posso provare a darti un indizio di ciò che potrebbe accadere:dipendenze mancanti nei Makefile.
Esempio:
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
Se chiami make target tutto verrà compilato correttamente. Compilazione di a.source viene eseguito (arbitrariamente, ma deterministicamente) per primo. Quindi la compilazione di b.source viene eseguita.
Ma se make -j2 target entrambi compile i comandi verranno eseguiti in parallelo. E noterai effettivamente che le dipendenze del tuo Makefile sono interrotte. La seconda compilazione presuppone a.bytecode è già compilato, ma non appare nelle dipendenze. Quindi è probabile che si verifichi un errore. La linea di dipendenza corretta per b.bytecode dovrebbe essere:
b.bytecode: b.source a.bytecode
Per tornare al tuo problema, se non sei fortunato è possibile che un comando si blocchi in un ciclo della CPU al 100%, a causa di una dipendenza mancante. Questo è probabilmente ciò che sta accadendo qui, la dipendenza mancante non può essere rivelata da una build sequenziale, ma è stata rivelata dalla tua build parallela.
Non so da quanto tempo hai la macchina, ma la mia prima raccomandazione sarebbe quella di provare un test della memoria e verificare che la memoria funzioni correttamente. So che spesso non è la memoria il problema, ma se lo è, è meglio eliminarla come causa prima di provare a rintracciare altri probabili problemi.
Mi rendo conto che questa è una domanda molto vecchia, ma appare ancora in cima ai risultati di ricerca, quindi ecco la mia soluzione:
GNU make ha un meccanismo di jobserver per garantire che make e i suoi figli ricorsivi non consumino più del numero specificato di core:http://make.mad-scientist.net/papers/jobserver-implementation/
Si basa su una pipe condivisa da tutti i processi. Ogni processo che desidera eseguire il fork di altri figli deve prima consumare i token dalla pipe, quindi abbandonarli al termine. Se un processo figlio non restituisce i token che ha consumato, il make while di livello superiore si blocca per sempre in attesa che vengano restituiti.
https://bugzilla.redhat.com/show_bug.cgi?id=654822
Ho riscontrato questo errore durante la creazione di binutils con GNU make sulla mia macchina Solaris, dove "sed" non è GNU sed. Giocherellare con PATH per fare in modo che sed==gsed abbia la priorità sul sistema sed ha risolto il problema. Non so perché sed stesse consumando token dalla pipe, però.