この正確な問題に対する答えはありませんが、何が起こっているのかについてヒントを与えることができます:Makefile の依存関係の欠落。
例:
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
make target を呼び出す場合 すべてが正しくコンパイルされます。 a.source のコンパイル が (任意に、しかし決定論的に) 最初に実行されます。次に b.source のコンパイル
しかし、もし make -j2 target 両方 compile コマンドは並行して実行されます。 Makefile の依存関係が壊れていることに実際に気付くでしょう。 2 番目のコンパイルでは a.bytecode を想定しています 既にコンパイルされていますが、依存関係には表示されません。そのため、エラーが発生する可能性があります。 b.bytecode の正しい依存関係行
b.bytecode: b.source a.bytecode
問題に戻ると、運が悪いと、依存関係がないためにコマンドが 100% CPU ループでハングする可能性があります。それがおそらくここで起こっていることです。欠落している依存関係は順次ビルドでは明らかにできませんでしたが、並列ビルドによって明らかになりました。
マシンをどれくらいの期間使用しているかはわかりませんが、最初にメモリ テストを試して、メモリが適切に機能していることを確認することをお勧めします。多くの場合、メモリが問題ではないことはわかっていますが、そうである場合は、他の可能性のある問題を追跡する前に、まず原因としてそれを排除することをお勧めします.
これは非常に古い質問だと思いますが、検索結果の上部にまだ表示されるので、ここに私の解決策を示します:
GNU make には、make とその再帰的な子プロセスが指定された数以上のコアを消費しないようにするジョブサーバー メカニズムがあります:http://make.mad-scientist.net/papers/jobserver-implementation/
すべてのプロセスで共有されるパイプに依存しています。追加の子プロセスをフォークしたい各プロセスは、最初にパイプからトークンを消費し、完了したらトークンを放棄する必要があります。子プロセスが消費したトークンを返さない場合、最上位の make while は返されるのを待って永久にハングします。
https://bugzilla.redhat.com/show_bug.cgi?id=654822
「sed」がGNU sedではないSolarisボックスでGNU makeを使用してbinutilsをビルドすると、このエラーが発生しました。 PATH をいじって sed==gsed をシステム sed より優先させると、問題が修正されました。ただし、sed がパイプからトークンを消費していた理由はわかりません。