MENU

LNK1104: mfc120.lib / mfc140.lib が見つからない時の連鎖依存特定法

ビルド
LNK1104: mfc120.lib / mfc140.lib が見つからない時の連鎖依存特定法

古いプロジェクトを Visual Studio 2026 で開いたとき、LNK1104: cannot open file 'mfc120.lib' や mfc140.lib のようなエラーが出ることがあります。設定にもコードにもその名前が見当たらない場合は、リンクしている別の .lib が古い MFC を要求している 可能性があります。

この記事では、その「見えない依存」を /VERBOSE:LIB で特定する手順をまとめます。本文では再現ログとして mfc90u.lib を使いますが、mfc120.lib や mfc140.lib でも見るべき場所は同じです。

原因切り分け：なぜ「書いていない」 mfc120.lib が要求されるのか

まず、同じ LNK1104 でも原因を分けて考えます。

状況最初に疑う場所
プロジェクト自身が古い Microsoft ライブラリを要求しているPlatform Toolset、MFC コンポーネント、VC++ ディレクトリ
リンクしている外部 .lib が古い MFC を要求している/VERBOSE:LIB で「どの .lib が要求したか」を特定する

今回の記事は 後者 です。リンクしているライブラリの中に、古い環境の既定ライブラリ指定が埋め込まれているケースを扱います。

C++ では #pragma comment(lib, "...") によって、ライブラリ検索レコードがオブジェクトに埋め込まれます。リンカーはその記録を見て、コマンドラインで指定されたのと同じように追加ライブラリを探します。

#pragma comment(lib, "mfc90u.lib")

つまり、あなたのプロジェクト側に mfc120.lib や mfc140.lib が書かれていなくても、リンクした別ライブラリの内部に古い指定が残っていれば、リンカーは律儀にそれを探しに行きます。

検証環境：
Visual Studio 2026
再現用ライブラリ： Visual Studio 2008 時代に作成した OldLib.lib

手順1：まずは /VERBOSE:LIB を有効にする

犯人探しをするには、リンカーに「どのライブラリを、どの順で探したか」を出させる必要があります。

  1. 対象プロジェクトの プロパティ を開きます。
  2. リンカー > 全般 を開きます。
  3. 詳細なリンカー出力の表示 を ライブラリの検索を表示 (/VERBOSE:LIB) に変更します。
  4. その状態で リビルド します。
Visual Studio 2026 のリンカー設定で /VERBOSE:LIB を有効にしている画面

/VERBOSE:LIB にすると、出力ウィンドウに「どのライブラリを検索したか」が流れます。一般的な /VERBOSE より、今回の調査ではこちらの方が見やすいです。

手順2：出力ウィンドウで「要求した側」を見つける

ビルドが失敗したら、エラー一覧ではなく出力ウィンドウ を見ます。目的は、mfc120.lib や mfc140.lib を誰が要求したかを特定することです。

  1. Ctrl + F で、エラーに出たファイル名を検索します。
  2. その少し手前にある ○○.lib を検索中 の行を探します。
  3. /DEFAULTLIB:... の行とセットで読みます。
OldLib.lib を検索中:
OldLib.lib(stdafx.obj) を読み込みました。
/DEFAULTLIB:mfc90u.lib オプションで処理を行いました。
LINK : fatal error LNK1104: ファイル 'mfc90u.lib' を開くことができません。

この並びなら、意味は明確です。OldLib.lib を読み込んだ結果、その内部にある /DEFAULTLIB:mfc90u.lib 指示が発火し、古い MFC ライブラリを探しに行って失敗した ということです。

ここで初めて、「設定に書いていないのに出るエラー」の犯人が特定できます。ポイントは、エラーになったファイル名だけでなく、その直前に読まれていた .lib を見ることです。

調査が終わったら /VERBOSE:LIB は戻してください。ログが増え、通常のビルドでは見づらくなります。

手順3：修正フローを選ぶ

犯人ライブラリが分かったら、対処は次の順番で考えるのが安全です。

  1. ソースがあるなら、依存ライブラリを現行環境でリビルドする
    これが最もきれいです。古い既定ライブラリ指定が消え、現行の toolset と MFC 構成で揃います。
  2. そのライブラリだけ古い toolset で維持する
    mfc120.lib や mfc140.lib のように比較的新しい版なら、対応 toolset を追加して旧構成のままビルドする選択肢があります。
  3. サードパーティ製なら、提供元から新しいビルドを入手する
    バイナリしかない場合は、現行 Visual Studio 向けに再ビルドされた版へ差し替えるのが基本です。

注意： Ignore Specific Default Libraries で古い MFC を無理に外して通す方法は、調査用には使えても、本番の修正としては安全とは限りません。依存ライブラリが本当にその版の MFC を前提に作られているなら、リンクが通っても実行時に別の問題になります。

mfc90u.lib のようにさらに古い版まで遡る場合は、現行環境だけで救えないことが多いです。その場合は、依存ライブラリの再ビルド か 新しい版への差し替え を前提に考えた方が早いです。

最終確認：単純な LNK1104 ではないかも見直す

もし犯人ライブラリが見つからない場合は、連鎖依存ではなく通常の LNK1104 の可能性があります。次を見直してください。

  • MFC コンポーネントが Visual Studio Installer で入っているか
  • Platform Toolset と Windows SDK が対象構成に入っているか
  • 追加のライブラリ ディレクトリや追加の依存ファイルに誤記がないか
  • x86 / x64、Debug / Release がズレていないか

一般的な LNK1104 の切り分けは、下記の記事にまとめています。今回のように「設定に書いていない古い MFC 名が出る」ケースだけを切り出して調べたい時は、まず本記事の手順で犯人ライブラリを特定してください。

MFCガイド
【MFC】LNK1104 / LNK2019 / LNK2001 ビルドエラー解決フロー：最短の確認順 – MFCガイド Visual Studio 2026 検証済み。MFCプロジェクトで頻発するリンクエラー(LNK1104, LNK2019, LNK2001)の原因と解決手順をフローチャート化。ライブラリ指定漏れや構成のズレ…

まとめ：再発防止チェックリスト

  • [ ] 版付き MFC ライブラリ名が出たら、まず /VERBOSE:LIB で要求元を特定する
  • [ ] エラーになったファイル名だけでなく、直前に読まれていた .lib を見る
  • [ ] ソースがある依存ライブラリは、できるだけ現行 toolset でリビルドする
  • [ ] mfc120.lib / mfc140.lib は toolset 依存の可能性もあると覚えておく

「書いていないはずの mfc120.lib が要求される」現象は、リンカーが勝手に壊れているのではなく、どこかの .lib が古い依存を持ち込んでいるだけです。出力ウィンドウで要求元まで追えれば、直すべき場所はかなり絞れます。

ビルド

関連記事