Je n'ai pas de réponse à ce problème précis, mais je peux essayer de vous donner un indice sur ce qui peut se passer :Dépendances manquantes dans les Makefiles.
Exemple :
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 vous appelez le make target tout se compilera correctement. Compilation de a.source est effectuée (arbitrairement, mais de manière déterministe) en premier. Puis compilation de b.source est effectuée.
Mais si vous make -j2 target les deux compile commandes seront exécutées en parallèle. Et vous remarquerez en fait que les dépendances de votre Makefile sont brisées. La deuxième compilation suppose a.bytecode est déjà compilé, mais il n'apparaît pas dans les dépendances. Une erreur est donc susceptible de se produire. La ligne de dépendance correcte pour b.bytecode devrait être :
b.bytecode: b.source a.bytecode
Pour revenir à votre problème, si vous n'êtes pas chanceux, il est possible qu'une commande se bloque dans une boucle 100% CPU, à cause d'une dépendance manquante. C'est probablement ce qui se passe ici, la dépendance manquante n'a pas pu être révélée par une construction séquentielle, mais elle a été révélée par votre construction parallèle.
Je ne sais pas depuis combien de temps vous avez la machine, mais ma première recommandation serait d'essayer un test de mémoire et de vérifier que la mémoire fonctionne correctement. Je sais que ce n'est souvent pas la mémoire qui pose problème, mais si c'est le cas, il est préférable de l'éliminer comme cause avant d'essayer de rechercher d'autres problèmes probables.
Je me rends compte que c'est une question très ancienne, mais elle apparaît toujours en haut des résultats de recherche, alors voici ma solution :
GNU make a un mécanisme jobserver pour s'assurer que make et ses enfants récursifs ne consomment pas plus que le nombre de cœurs spécifié :http://make.mad-scientist.net/papers/jobserver-implementation/
Il s'appuie sur un tuyau partagé par tous les processus. Chaque processus qui souhaite forker des enfants supplémentaires doit d'abord consommer des jetons du canal, puis les abandonner une fois terminé. Si un processus enfant ne renvoie pas les jetons qu'il a consommés, le make while de niveau supérieur se bloque indéfiniment en attendant qu'ils soient renvoyés.
https://bugzilla.redhat.com/show_bug.cgi?id=654822
J'ai rencontré cette erreur lors de la construction de binutils avec GNU make sur ma machine Solaris, où "sed" n'est pas GNU sed. Jouer avec PATH pour que sed==gsed ait la priorité sur le système sed a résolu le problème. Cependant, je ne sais pas pourquoi sed consommait des jetons du tuyau.