moldのRust書き換え、Linuxの標準リンカを目指す

Rui Ueyama氏が、mold（モールド）をC++からRust（ラスト）へ書き直しています。moldはLinuxで使える最速級のリンカの一つです。Phoronixは2026年9月11日に報じました。この書き換えが、次期3.x系列の中心になるという内容です。開発者が注目すべきなのは二つ目の目標です。moldは、Linuxディストリビューションに自らを/usr/bin/ldとして、つまりあらゆるビルドが使う標準リンカとしてインストールしてもらうことを望んでいます。

リンカはビルドの最後の工程です。コンパイラが各ソースファイルをオブジェクトファイルに変換します。リンカはそれらのオブジェクトとライブラリをつなぎ合わせ、実行できる一つのプログラムにします。大規模なC++やRustのプロジェクトでは、この最後の工程が待ち時間を決めることがよくあります。

その差は大きいものです。Phoronixは具体的な数字で説明しました。moldが「数百ミリ秒」で終えるリンク作業が、「標準のリンカでは数秒、数十秒、あるいは数分」かかることもあります。

moldのリポジトリは、中央値でLLVMのlldより4.9倍、wildより1.9倍速くリンクすると主張しています。Ueyama氏はlldも書いた人物であり、自分の過去の作品と競っていることになります。このプロジェクトは2021年から実運用されています。x86-64、ARM、RISC-V、PowerPC、s390x、LoongArch、SPARC64を含む14のCPUアーキテクチャに対応しています。

なぜRustなのか、そしてなぜ今なのか

Ueyama氏は、2026年9月1日に始まったmoldのGitHubリポジトリのピン留めされた議論で理由を述べました。第一はメモリ安全性です。リンカは自分が作ったのではないオブジェクトファイルを読み、ポインタ演算を大量に行います。まさにそこが、メモリのバグを書きやすく、見つけにくい場所です。

彼は開発ツールの環境にも触れています。Rustは依存関係を管理するCargoを標準で備え、クロスコンパイルも簡単にします。14のアーキテクチャ向けにビルドしなければならないツールにとって、どちらも重要です。moldの現在の言語であるC++20は、そのどちらも標準では提供しません。

議論を呼ぶのは、時期についての主張でしょう。Ueyama氏は、この書き換えが現実的な費用で可能になったのはAIコーディングツールのおかげだとしています。「AIによる書き換え支援は、この種の作業のコストを劇的に変えました」と彼は書いています。「昨年ならおそらく挑戦しなかったでしょうが、今日では驚くほどわずかな労力で済みます」。

彼はこの選択を長期的な賭けだと表現しました。「この決定は、今そう見えるよりも、10年か20年後に振り返ったときのほうが納得できるものになるでしょう」。

今年は他のプロジェクトも同じ道を進んでいます。Bun 1.4はRustへの書き換えを実運用に投入しました。また、Rustでゼロから書かれたX11サーバーであるYSERVER 1.5は、初期のコードをAIの助けを借りて書いています。

/usr/bin/ldになることのほうが難しい

リンカが標準になるのを妨げるのは速度ではありません。互換性です。GNU ldと、その高速版であるgoldには、数十年ぶんの動作が積み重なっています。ビルドスクリプトはそれに暗黙のうちに依存しています。リンカスクリプトの文法から、ほとんど知られていないコマンドラインオプションまでさまざまです。

プロジェクト側もそれを理解しています。「mold 3.x系列の主要な目標の一つは、Linuxディストリビューションが/usr/bin/ldとして採用できるmoldにすることです」とPhoronixは報じました。書き換え後の計画は、時間をかけた協調的なものです。「その後、大規模な互換性テストを実施し、Linuxディストリビューションの開発者と緊密に協力します」。

工程	状況
moldをC++からRustへ書き換える	進行中、3.x系列が目標
大規模な互換性テスト	書き換え後に予定
ディストリビューション開発者との調整	テスト後に予定
/usr/bin/ldとして標準で提供	未定

採用を約束したディストリビューションはありません。これらの工程のいずれについても、日程は示されていません。

開発者にとっての意味

今日壊れるものは何もありません。mold 2.xはそのまま残り、Rustによる書き換えはリリース日の決まっていない将来の3.x系列に入ります。

moldを試したことがないなら、今週はどれだけ短縮できるかを測るよい機会です。Linuxのツールチェーンなら、-fuse-ld=moldを付けてビルドを一つだけ切り替えられます。そのうえで、リンク工程を現在の標準と比べてみてください。オブジェクトファイルが多く、大きな静的ライブラリを使うプロジェクトほど差が大きく出ます。小さなプロジェクトでは差が出ないこともあります。

ビルドシステムやディストリビューションのパッケージを保守しているなら、意見が効いてくるのは互換性テストの段階です。独自のリンカスクリプト、珍しいオプション、リンク時最適化の設定が、最も差の出やすい部分です。Ueyama氏は、標準が変わる前にディストリビューションの開発者に加わってほしいと明言しています。

リンカとは別に、もう一つ注目すべき点があります。広く使われているシステムツールの保守担当者が、AIの支援によって挑戦できる書き換えの範囲が変わったと公に述べたことです。その判断が正しかったかどうかは、3.x系列がコードで答えを出します。主張ではなく、結果に照らして確かめる価値があります。