Visual Studio 2022で静的ライブラリ(.lib)が生成されない原因とSTL4043警告の対処法【Crypto++対応】

Visual Studio 2022 で Crypto++ を静的ライブラリとしてビルドしようとしたところ、STL4043 警告が大量に発生し、目的の .lib ファイルが生成されない…。本記事では、この現象の正体と原因、そして確実に .lib を出力させるためのチェックポイントや設定例を、初心者から中級者までわかるように整理して解説します。

目次

静的ライブラリ(.lib)が生成されない現象の概要

まずは、今回のトラブルの前提条件を整理します。

  • OS: Windows 11 24H2
  • IDE: Visual Studio 2022
  • 言語規格: C++20
  • ライブラリ: Crypto++(cryptopp)を静的ライブラリとしてビルド

この環境で Crypto++ のプロジェクトをビルドすると、ビルドログに STL4043 警告が大量に表示され、最終的に期待している cryptopp.lib(あるいは任意の .lib)が出力されない、という状況になります。

STL4043 警告の内容

代表的なメッセージは次のようなものです。

warning STL4043: stdext::checked_array_iterator は非標準の機能であり、
将来のバージョンの C++ 標準ライブラリから削除される予定です。
この警告を抑制するには、_SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING
または _SILENCE_ALL_MS_EXT_DEPRECATION_WARNINGS を定義してください。

同様のメッセージが stdext::unchecked_array_iterator に対しても出力されます。要するに、

  • これらの型は MSVC 固有の拡張機能 であり、
  • 将来の標準ライブラリでは削除される可能性があるため、非推奨 として警告が出ている

ということです。

「警告なのに .lib が出ない」のはなぜか

STL4043 自体はあくまで「警告」です。しかし Visual Studio の設定によっては、

  • 警告をエラーとして扱う(/WX)

が有効になっている場合があります。この状態でビルドすると、警告が 1 件でも発生した時点でコンパイルは 失敗(エラー扱い) となります。結果として、

  • コンパイルエラー扱い → ビルド失敗
  • ビルド失敗 → .lib のリンク処理まで到達しない

という流れになり、「エラー 0 件なのに .lib が出ない」ように見えてしまう場合があります。実際には、

  • 「警告 = 事実上のエラー」に格上げされている

ことが原因です。

.lib が生成されないときに最初に見るべきチェックリスト

STL4043 が出ているかどうかに関わらず、「.lib ができない」トラブルでまず確認したい項目を表にまとめます。Crypto++ に限らず、他のライブラリでもそのまま使えるチェックリストです。

ビルド構成・出力まわりの基本チェック

チェック項目設定場所目安となる設定値
構成の種類構成プロパティ → 全般 → 構成の種類静的ライブラリ (.lib)
出力ディレクトリ構成プロパティ → 全般 → 出力ディレクトリ$(SolutionDir)x64\Debug\ など
出力ファイル名Librarian → 全般 → 出力ファイル$(OutDir)cryptopp.lib など
プラットフォームツールバーの構成プラットフォームx64 / Win32 など、意図したもの
ビルド結果出力ウィンドウエラー 0、警告 N(または エラー N)

警告まわりのチェック

チェック項目設定場所目安となる設定値
警告をエラーとして扱うC/C++ → 全般 → 警告をエラーとして扱ういいえ (/WX-)
特定の警告をエラーに昇格C/C++ → 詳細設定 → 特定の警告をエラーとして扱う空欄(または、問題ない警告番号のみ)
STL4043 の抑制マクロC/C++ → プリプロセッサ → プリプロセッサ定義_SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING を追加

特に Debug / Release や Win32 / x64 など、構成ごとに設定が別管理されている点に注意してください。Debug 構成でだけ /WX が有効になっている、といったケースは非常に多いです。

STL4043 警告を抑制してビルドを通す手順

STL4043 警告を「一旦は無視して」ビルドを通したい場合、Visual Studio のプロパティでマクロを定義するのが最も簡単です。

プロパティシートから設定する方法

  1. ソリューションエクスプローラーで Crypto++ のプロジェクトを右クリックし、「プロパティ」を開く。
  2. 「構成」コンボボックスで、「すべての構成」 を選択。
  3. 左ペインで「C/C++ → プリプロセッサ」を選択。
  4. 「プリプロセッサ定義」に以下のいずれかを追記する。
    • _SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING
    • または _SILENCE_ALL_MS_EXT_DEPRECATION_WARNINGS
  5. 「OK」で保存し、プロジェクトを再ビルド。

1 行追加するだけですが、どちらを使うべきかは影響範囲が異なります。

マクロ抑制される警告特徴おすすめ度
_SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNINGSTL4043(stdext::checked/unchecked_array_iterator 周り)影響範囲が最小。Crypto++ のビルドだけを静かにしたい場合に適している。高
_SILENCE_ALL_MS_EXT_DEPRECATION_WARNINGSMS 拡張に関する非推奨警告すべて将来の移行の目安になる警告までまとめて消えてしまうリスクがある。中(状況によっては有効だが慎重に)

プロダクションコードや長期運用を前提にするなら、まずは 個別マクロ の定義を推奨します。

コマンドライン(cl.exe)から設定する場合

MSBuild やバッチファイルで直接 cl.exe を呼び出している場合は、コンパイルオプションに /D オプションを追加します。

cl /c /std:c++20 /D_SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING ...

CMake を使っている場合は、次のようにプリプロセッサ定義を追加できます。

add_definitions(-D_SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING)

よりモダンな CMake では、ターゲットごとに次のように書く方法もあります。

target_compile_definitions(cryptopp_static PRIVATE
    _SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING
)

.lib が生成されない典型的な原因と対処

STL4043 以外にも、「.lib が出ない」原因はいくつかのパターンに分けられます。Crypto++ 以外でも役に立つ切り分け方なので、一覧で整理しておきます。

パターン 1: 警告がエラー扱いになっている(/WX)

最も多いパターンがこれです。

  • C/C++ → 全般 → 警告をエラーとして扱う が「はい」になっている
  • あるいは C/C++ → 詳細設定 → 特定の警告をエラーとして扱う に STL4043 などが列挙されている

対処としては次のいずれかです。

  • 一時的回避: ライブラリビルドに限って /WX を無効化する
  • 恒久対処: ライブラリ側では警告を抑制し、アプリ側では /WX を維持する

後者の方が安全で、既存のプロジェクトポリシー(「警告はゼロに」)を崩さずに済みます。ライブラリ(外部コード)は専用のプロジェクトに切り出し、そこでのみマクロを定義しておくと管理がしやすくなります。

パターン 2: 構成の種類が「アプリケーション」になっている

静的ライブラリを作りたいのに、プロジェクトの「構成の種類」が アプリケーション のままになっていると、ビルドの最終成果物は .exe になってしまいます。ビルド自体は成功しているのに .lib が見つからない場合は、この設定ミスを疑いましょう。

確認手順:

  1. プロジェクトを右クリック → 「プロパティ」。
  2. 「構成プロパティ → 全般 → 構成の種類」を開く。
  3. 「静的ライブラリ(.lib)」を選択する。

既存プロジェクトを流用したときに見落としやすいポイントです。

パターン 3: 出力先フォルダやファイル名の勘違い

ビルドは成功しているのに、エクスプローラーで .lib が見当たらない…。その場合は、

  • 出力ディレクトリ(OutDir) がどこを指しているか
  • 出力ファイル名 が想定と一致しているか

を確認します。

Visual Studio のデフォルトでは、

  • $(SolutionDir)$(Configuration)\ など、構成ごとに別フォルダ

に出力されることが多く、「Debug フォルダにはあるが Release にはない」「x64 と Win32 で場所が違う」といった勘違いがよく起こります。

意外と有効なのが、Windows の検索ボックスで *.lib を検索してしまう方法です。ビルド直後であれば、どこに出力されたかを素早く特定できます。

パターン 4: 一部のソースファイルだけコンパイルに失敗している

ビルドログの末尾だけを見て「エラーはない」と判断してしまうと、途中でコンパイルに失敗しているファイルを見落とすことがあります。特に Crypto++ のようにソースファイル数が多いライブラリでは、

  • 前半のファイルでエラー発生 → そのファイルのオブジェクトが生成されない
  • しかし残りのファイルはビルドされるため、一見「ビルドは進んでいる」ように見える

といった状況になります。

確実に確認したい場合は、

  • 「出力」ウィンドウの表示を「ビルド」にし、スクロールバーを一番上まで戻す
  • 「エラー一覧」ウィンドウで「すべてのメッセージを表示」に切り替える

などして、ビルド全体のログをチェックしましょう。特定の .cpp でエラーが出ている場合、そのファイルのみに限定して一時的に #pragma warning(disable: XXXX) を追加するという戦術もあります。

パターン 5: プラットフォームや言語設定の不整合

サンプルで提供されている .vcxproj ファイルを流用した場合、

  • プロジェクト設定は x86 用だが、ソリューションは x64 でビルドしている
  • 言語規格が C++20 ではなく、C++17 / C++14 のまま

などの不整合が残っていることがあります。Crypto++ 自体は幅広いコンパイラで動作するよう配慮されていますが、

  • Visual Studio のバージョン固有の挙動
  • 新しい標準ライブラリの仕様変更

の影響で、特定の組み合わせだけビルドが通らないケースもあり得ます。構成プロパティの「C/C++ → 言語 → 言語標準」が C++20 になっているかも合わせて確認しておきましょう。

MSBuild ログから原因を読み解くコツ

より本格的に原因を追いかけたい場合は、MSBuild のログ出力レベルを上げて詳細ログを取得するのも有効です。Visual Studio からでも、次のようにして詳しいログを確認できます。

  • 「ツール → オプション → プロジェクトおよびソリューション → ビルドおよび実行 → MSBuild プロジェクト ビルド出力の詳細度」

を「詳細(または診断)」に設定してからビルドすると、

  • どのファイルがどのオプションでコンパイルされているか
  • どのタイミングでエラー/警告が出ているか
  • 最終的にどのコマンドで lib.exe が呼び出されているか

がわかります。

ログの末尾付近で、次のようなコマンド行が存在するか確認してみてください。

lib.exe /OUT:"...\cryptopp.lib" ...

この行が出ていない場合は、そもそもリンクステップ(ライブラリアン)が実行されていないということになります。つまり、その手前でコンパイルエラー(または警告エラー)が発生していると考えられます。

将来を見据えた Crypto++ / Visual Studio の付き合い方

STL4043 を単に「消す」だけなら、マクロを 1 つ定義すれば終わりです。しかし、長期的には次のような観点も押さえておくと安心です。

MS 拡張への依存を減らしていく

STL4043 が示している通り、stdext::checked_array_iterator / unchecked_array_iterator は MSVC 固有の拡張です。Visual Studio の将来のバージョンでは、本当に削除される可能性があります。

Crypto++ 本体がアップデートされるにつれて、

  • 標準 C++ の機能(例: std::span や std::array)
  • またはコンパイラ非依存のテクニック

に徐々に移行していく流れが予想されます。そのため、

  • ライブラリのバージョンを定期的に追従する
  • 新しいバージョンで警告が消えていないか確認する

といった運用を取り入れておくと、将来の大規模な修正を避けやすくなります。

「外部ライブラリ用のプロジェクト」を分離する

実務的には、次のような構成にしておくと、警告やコンパイラオプションの方針を柔軟に切り替えられます。

  • アプリケーション本体: 自社コードのみ。警告は厳格に /WX を適用。
  • サードパーティライブラリ用ソリューション(またはプロジェクト): 各ライブラリごとに最適な設定を個別に適用。

たとえば、

  • Crypto++ プロジェクトでは _SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING を定義
  • アプリケーションプロジェクトでは上記マクロを定義しない(警告を検知する)

というように、ソースコードの性質に応じてビルドポリシーを分けることができます。

CI / CD 環境での再現性を高める

GitHub Actions や Azure Pipelines などの CI を使っている場合、

  • ローカルの Visual Studio
  • ビルドサーバー上のコンパイラ

でインストールされているツールセットのバージョンが違うと、警告・エラーの挙動が変わることがあります。次のような情報をレポジトリに明記しておくと、トラブルシューティングが容易になります。

  • 想定している Visual Studio / MSVC のバージョン
  • 必要なワークロード・コンポーネント
  • Crypto++ のバージョンと取得方法(ソースを直接置くのか、パッケージ管理ツールを使うのか など)

CI 用のビルドスクリプトにも、今回紹介したマクロ定義や /WX 設定を明示しておくと、「ローカルでは通るのに CI では落ちる」といったズレを減らせます。

CMake / MSBuild で Crypto++ を静的ライブラリとしてビルドする場合の例

最後に、CMake などのビルドシステムから Visual Studio を叩く場合の設定例を簡単に紹介します。ポイントは、

  • ターゲットを静的ライブラリとして定義する
  • MSVC のときだけ警告抑制マクロを定義する

という 2 点です。

cmake_minimum_required(VERSION 3.20)
project(cryptopp_static_lib CXX)

add_library(cryptopp_static STATIC
    cryptlib.cpp
    aes.cpp
    // ここに Crypto++ の .cpp を列挙
)

target_compile_features(cryptopp_static PRIVATE cxx_std_20)

# MSVC のときだけ警告抑制マクロを追加
if (MSVC)
    target_compile_definitions(cryptopp_static PRIVATE
        _SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING
    )
endif()

このようにしておけば、GCC / Clang 環境では警告抑制マクロが定義されず、MSVC でビルドするときだけ STL4043 を黙らせることができます。

今日から実践できるチェック手順まとめ

最後に、この記事で扱ったポイントを「実際に手を動かすときの手順」としてまとめます。Crypto++ に限らず、他の静的ライブラリをビルドするときにも使えるチェックリストです。

  1. ビルドログを確認する
    • 「出力」ウィンドウで「ビルド」を選択し、エラー・警告の内容を頭から通して読む。
    • STL4043 などの警告が出ていないか確認する。
  2. 構成の種類を確認する
    • 構成プロパティ → 全般 → 構成の種類が「静的ライブラリ (.lib)」になっているか。
  3. /WX の有無を確認する
    • C/C++ → 全般 → 警告をエラーとして扱う(/WX)が「いいえ」かどうか。
    • 必要に応じて、サードパーティ用プロジェクトだけ /WX を無効にする。
  4. 警告抑制マクロを定義する
    • C/C++ → プリプロセッサ → プリプロセッサ定義に _SILENCE_STDEXT_ARR_ITERS_DEPRECATION_WARNING を追加。
    • 影響範囲を意識して、可能な限り個別マクロを使う。
  5. 出力パスとファイル名を確認する
    • Librarian → 全般 → 出力ファイル を確認し、期待したフォルダ・ファイル名かどうかを見る。
    • エクスプローラーや検索で、実際に .lib がどこに生成されているかを確認する。
  6. 自動ビルド環境にも同じ設定を反映する
    • CMake / MSBuild の設定ファイルにマクロ定義や /WX オプションを明示的に記載する。
    • ローカルと CI でビルド条件が一致するようにする。

これらを順番に確認していけば、「STL4043 警告が山ほど出て、.lib が一向に生成されない」という状況から抜け出すことができます。特に、Visual Studio 2022 以降は標準ライブラリの実装が活発に更新されているため、今後も似たような非推奨警告が増えていくことが予想されます。

そのときに重要なのは、

  • 「警告を全部消す」のか、「必要なものだけを選んで抑制するのか」

という方針をチーム内で共有しておくことです。今回紹介したように、外部ライブラリと自前コードでビルドポリシーを分けることで、

  • 自前コードの品質を落とさず
  • サードパーティライブラリも安全に活用する

というバランスを取りやすくなります。本記事をベースに、自分のプロジェクトに最適な設定・運用ルールを整えてみてください。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次