Rust「linker link.exe not found」の原因と直し方

要約

error: linker "link.exe" not found は、コンパイルではなくリンクの段階で出るエラーだ。

Windows 版の Rust は既定で x86_64-pc-windows-msvc ターゲットを使い、最後のリンクを Microsoft のリンカー（link.exe）に任せる。
rustup はこのリンカーを同梱しないため、Visual Studio 側のビルドツールが無い端末では必ずここで止まる。

Rust 自体の入れ直しでは直らない。
リンカーを用意するか、リンカーを必要としないツールチェーンに切り替えるかのどちらかである。

解決策

1. C++ ビルドツールを入れる（推奨）

rustup の公式ドキュメントが案内している標準的な手順である。
Visual Studio Build Tools のインストーラーを起動し、ワークロードから C++ によるデスクトップ開発 を選ぶ。
個別コンポーネントとしては、MSVC のビルドツールと Windows SDK の 2 つが必要だ。

インストールが終わったらターミナルを開き直し、リンカーが見えるか確認する。

where.exe link.exe
cargo build

Visual Studio 本体を使っている場合は、同じワークロードが入っていれば追加のインストールは要らない。

2. GNU ツールチェーンへ切り替える

MSVC を入れられない環境では、GNU ツールチェーンに切り替える手もある。
この場合は MinGW-w64 の gcc がリンカーの役目を果たす。

rustup toolchain install stable-x86_64-pc-windows-gnu
rustup default stable-x86_64-pc-windows-gnu
cargo clean
cargo build

ただし GNU ツールチェーンは、MSVC 向けにビルドされたクレートやシステムライブラリとの相性で別の問題が出ることがある。
配布物を Windows で動かすのが目的なら、MSVC 側を整えるほうが結局は近道だ。

3. いま使っているターゲットを確認する

どちらのツールチェーンで動いているのかは、次のコマンドの host 行で分かる。

rustc --version --verbose

host: x86_64-pc-windows-msvc と出ていれば MSVC、...-windows-gnu なら GNU だ。
切り替えたつもりで切り替わっていない、という取り違えはここで潰せる。

4. 切り替え後は cargo clean を挟む

ツールチェーンを変えると成果物の形式も変わる。target/ に前のターゲットの中間生成物が残っていると、リンク段階で不可解な失敗をすることがあるため、切り替え直後は cargo clean を一度実行しておくと余計な回り道をせずに済む。

よくある原因

1. Visual Studio も Build Tools も入っていない。
   新しい端末で rustup だけ入れたときの定番だ。
2. Build Tools のインストーラーは実行したが、ワークロードを選ばずに閉じた。
   インストーラーは既定で何も選ばないため、本体だけ入って link.exe は入らない。
3. インストール直後の古いターミナルでそのまま cargo build した。PATH の変更は新しいプロセスにしか反映されない。
4. ネット上の手順が GNU ツールチェーン前提だった。
   MinGW-w64 を入れても、MSVC ターゲットのままでは link.exe を探し続ける。