WindowsでSwiftを使うと出る「machine type conflicts」リンカーエラーの原因と解決策まとめ

Windows環境でSwiftを使っていたら、アップデート後に突然リンクが通らなくなった。最初は memcpy など標準関数が見つからない系のエラーだったのに、Visual Studioを更新したら今度は msvcrt.lib(chkstk.obj): machine type x86 conflicts with x64 が出る——このパターンは、Windows開発環境の「32bit/64bitの食い違い」が表面化した典型例です。この記事では、なぜ起きるのか、どこを直せば最短で収束するのかを、手順として整理します。

WindowsでSwiftを使うと出る「machine type conflicts」リンカーエラーの原因と解決策まとめ

エラーの意味：x86とx64が混ざっているだけ（ただし発生源は複数ある）

エラーメッセージの核心はこれです。

msvcrt.lib の中にある chkstk.obj が x86（32bit）向け
いまリンクしようとしている成果物（Swiftやあなたのビルド対象）は x64（64bit）向け
よって lld-link（LLVMのWindows用リンカー）が「混在している」と判断して停止する

chkstk はスタック確保で使われる低レベル処理の一部で、ランタイムライブラリ側のオブジェクトです。つまり、あなたのコードが悪いというより 参照しているCランタイム（CRT）やライブラリの向きがズレている 可能性が高いです。

なぜアップデート後に起きやすいのか：VS側のツールチェーン選択が変わる

Swift on Windows は内部で clang/lld を使いつつ、Windowsの世界では結局 MSVC のヘッダやライブラリ（UCRT/VC Runtime）にも依存します。Visual StudioやBuild Toolsの更新で、次のような「選択」が変わると壊れます。

環境変数（LIB, INCLUDE, PATH）が別の優先順になった
x86用のライブラリパスが先に拾われるようになった
古いWindows SDK／VCツールセットが残り、それが参照される
“Developer Command Prompt” を使っていない（またはx86用を開いている）

結果として、64bitを作っているのに、リンカーが32bitの msvcrt.lib を拾う、という事故が起きます。

よくある根本原因トップ5

ここを押さえると、原因切り分けが速いです。

1) x86用の開発者コマンドプロンプトでビルドしている

Visual Studioには「x64 Native Tools」「x86 Native Tools」など複数のプロンプトがあります。x86側で環境が初期化されていると、LIB がx86ライブラリを指しがちです。

2) `LIB` / `PATH` に古いSDKや別ツールチェーンが混ざっている

過去に入れたLLVM、MinGW、古いWindows SDKなどが PATH の前方にあると、意図しない link.exe や lib.exe、ライブラリ探索パスが使われることがあります。Swiftは lld-link を使うとはいえ、参照パスの汚染でx86資産が混入します。

3) Visual Studio更新で「必要なコンポーネント」が外れている

VS更新後、C++関連のワークロードが部分的に欠けると、正しいx64 CRTが見つからず、別の互換ライブラリを拾ってしまうことがあります。

4) ビルド設定がx64になっていない（または自動で切り替わっていない）

CMakeやSwiftPM、独自スクリプトが、既定でWin32（x86）を選ぶケースがあります。片方がx64、片方がx86の“ハイブリッド”が最悪です。

5) 既存ビルド成果物（キャッシュ）が32bitのまま残っている

一度x86で生成された中間生成物や依存ライブラリが残っていると、設定を直しても混入し続けます。

まずやるべき最短ルートの対処（手順）

ここからは「順番」が大事です。上から潰すほど再現性高く直ります。

手順1：x64環境でビルドしていることを固定する

Visual Studioの “x64 Native Tools Command Prompt for VS” を使う
そのシェル内で swift --version、clang --version を確認し、ビルドを実行する

ポイントは「いつものPowerShell/Command Prompt」ではなく、x64前提の環境変数がセットされた状態で走らせることです。

手順2：どの `msvcrt.lib` を拾っているかを突き止める

リンカーは「どのパスのライブラリを見たか」を出せます。lld-link によって表現は異なりますが、ビルドログを詳細化して msvcrt.lib の実体パス を見つけるのが重要です。

もし .../lib/x86/.../msvcrt.lib を拾っていたら確定で環境問題です
正しくは .../lib/x64/... あるいは .../um/x64 / .../ucrt/x64 系が絡みます

「どこから拾ったか」が分かれば、直すべきは パス順 だと断定できます。

手順3：環境変数の汚染を一度リセットする

LIB と INCLUDE に手動で追加しているものがあれば外す
PATH の先頭付近に入れているLLVM/MinGW/古いSDKを一旦後ろへ
可能なら “x64 Native Tools Command Prompt” のクリーンな状態で試す

Swift on Windowsは「WindowsのC/C++資産に寄り添う」ため、汚れた環境変数の影響を強く受けます。

手順4：Visual Studio Installerでコンポーネントを確認する

最低限、次の系統が揃っているかを確認します。

Desktop development with C++（C++デスクトップ開発）
MSVC v14x x64/x86 build tools（x64が入っていること）
Windows 10/11 SDK（複数あってもよいが、整合していること）

不足があると、正しいx64 CRTへ到達できず、別のものを拾うケースがあります。

手順5：ビルド成果物を全消しして作り直す

キャッシュが残ると、直したつもりでも混入が続きます。

SwiftPMなら .build を削除
CMakeなら build/ を削除して再生成
依存ライブラリを自前ビルドしているなら、それもx64で作り直す

「x86で作られた .lib や .obj が残っていない」状態を作るのがゴールです。

`memcpy` が見つからない系のエラーも同じ根っこで起きる

最初に出ていた「memcpy のようなものが解決できない」エラーは、一見別問題に見えますが、実務的には同系統です。

UCRTやMSVCランタイムの参照が壊れている
参照はできているが、向き（x86/x64）が違ってシンボル解決が崩れている
ヘッダ/ライブラリの組み合わせがSDK間でズレている

つまり、今回の machine type conflicts は「より分かりやすい形で破綻が表に出ただけ」と考えると整理しやすいです。

Swift 6.1のままでも直る？更新は必要？

Swiftの更新（6.1→6.2など）が直接の解決になるケースもゼロではありませんが、このエラー文面に限っては ほぼ環境（VS/SDK/パス）の問題 です。優先順位としては、

x64のツールチェーンとSDK参照を正す
混入したx86資産を排除する
それでもダメならSwift側の更新や再インストールを検討

が最短です。Swiftのバージョンを上げる前に、まず「どの msvcrt.lib を拾っているか」を突き止めるのが勝ち筋になります。

まとめ：直すべきはコードではなく“参照しているライブラリの向き”

msvcrt.lib(chkstk.obj): machine type x86 conflicts with x64 は、Windows開発で最も頻出する「32bit/64bit混在」エラーの代表格です。対処は難しく見えて、要点はシンプルです。

x64の開発者コマンド環境でビルドする
msvcrt.lib の実体パスを特定し、x86を拾わないようにする
キャッシュと既存生成物を消して、x64で作り直す

この3点を押さえると、多くの場合は短時間で収束します。環境更新後に突然壊れたときほど、「参照先が変わった」可能性を疑い、ライブラリ探索パスの確認から入るのが最も堅実です。