静的ライブラリをリリースビルドとデバッグビルドで共用したい。

Question

はじめましてこんばんは。

C/C++でのお話です。

一般的に配布されている（？）静的ライブラリはリリースビルドとデバッグビルドで共通のものが使用されていると思っています。例えば libvulkan-1.a や d3d12.lib など

そのため、自分で .lib もしくは lib.a ファイルを作成するときにも共用できるタイプで作成したいと思いました。
しかし、.obj もしくは .o ファイルを作成する際に、-D_DEBUG や -DNDEBUG などのデバッグ用とリリース用で異なるプリプロセッサフラグを指定する場合があります。
そうすると .obj ファイルから .lib ファイルを作成するときにデバッグもしくはリリース用で固定されてしまいます。

そこで質問なのですが、これを回避し、デバッグビルドとリリースビルドで共通して使える .lib ファイルは作成できるのでしょうか？

自分の予想

vulkan-1.lib と d3d12.lib には対応するランタイム dll（vulkan-1.dll, d3d12.dll）が OS に入っていることや、c++ - Debug版とRelease版で同じLibファイルにする方法 - スタック・オーバーフロー を見た感じ、 .lib ファイル単体では共通して使用できず、共通して利用するには .dll または lib.so ファイルが必要なのかな。と思いました。
ただ、.dll に関して完全に無知なのでよく分かりません。教えてください。

環境

Windows 10 64bit
MSYS2 MinGW x64 - GCC 11.2.0

免責

初めての投稿ということで至らぬ点があるかと思いますが、優しく指摘していただけると嬉しいです。

Answer 1

debug-buildされたライブラリはその名の通りデバッグ用。なのでrelease時には不要な/余計なデータ/実行コードがみっちり詰め込まれています。

そんなのを本番(release版)でも使いたいんですか?

※ Linux(gcc/g++)なら、デバッグのために(-g オプションで)付加した情報をそぎ落とすことができますけどね。
https://linuxjm.osdn.jp/html/GNU_binutils/man1/strip.1.html

Comments

[YUKI_DAYO]

回答ありがとうございます。

> しかし、.obj もしくは .o ファイルを作成する際に、-D_DEBUG や -DNDEBUG などのデバッグ用とリリース用で異なるプリプロセッサフラグを指定する場合があります。
> そうすると .obj ファイルから .lib ファイルを作成するときにデバッグもしくはリリース用で固定されてしまいます。
>
> そこで質問なのですが、これを回避し、デバッグビルドとリリースビルドで共通して使える .lib ファイルは作成できるのでしょうか？

と述べたように、デバッグビルドで生成された .lib ファイルをリリースビルドで使用する事を望んでいるわけではありません。（逆も然りです）

@episteme さんがおっしゃる通り、普通に .obj ファイルから .lib ファイルを作成すると .obj ファイルを作成したビルドタイプ専用になってしまいます。

ですが、例えば Win32 API でアプリケーションを作成する場合、デバッグビルドでもリリースビルドでもリンクする静的ライブラリファイルは同じですよね？（`gdi32.lib`など）
その仕組みを知りたいのです。

[episteme]

release用ライブラリをアプリのdebug用にリンクしてるだけじゃないかしら...
ライブラリのdebugをしたいわけじゃないから、ライブラリにはdebug情報要らんでしょ。ってことでは?

[YUKI_DAYO]

なるほど…
じゃあ静的ライブラリにデバッグ用なるものは存在しないということなんですかね。

基本的にアーカイブするオブジェクトファイルは stable ですし…

[episteme]

＞じゃあ静的ライブラリにデバッグ用なるものは存在しないということなんですかね。
んなこたーない。

あなたがライブラリを作ってて、
そいつをdebugしたいならdebug-buildし、
リリース時にはrelease-buildすればいい。

[fana]

（無知な初心者の便乗質問になりますが）
ライブラリ側　と　それを使う側　とで　デバッグ/リリース　が異なるとき，
例えば一方で new したものを他方で delete した際とかに異常事態になったりしないのでしょうか？

[episteme]

Debug版はコードとそれに対する機械語との対応表が追加されたもの(シンボリック・デバッグのため)であるはず原則的に。あとDebug版は(通常)オプティマイズを軽くします。

calling-conventionが変わると厄介でしょうね(呼べなく/帰れなくなるから)。
だからそれはないだろうし、やっちゃいけないんだろうと。

# そもそもdebug版ライブラリはコードも一緒に用意しないとシンボリック・デバッグできんしなぁ...

[fana]

うーん，何だろう，良く分かってないですが，

lib側が使う C/C++ のランタイム(?)　と libを用いるAPP側が使うランタイム　とで デバッグ版/リリース版 が異なってしまう場合に，動作の不整合が起きたりしないのか？　っていう．

（new/delete みたいに 対になる物 はそういう話が特にありそうかな？と思ったので例に挙げた）

[退会済みユーザー]

> fana
ヘッダオンリーライブラリでもなければ、普通はライブラリ側で確保したメモリは、ライブラリ側で解放するように作るんじゃないですかね。（COMオブジェクトのIUnknown::Release的なやつ）
リリース/デバッグ関係なしに、メモリアロケータが違った場合に死ぬので。

[episteme]

DLLがnewした領域はDLLでdeleteせんとコケたりしますね。メモリ空間がEXEと異なるとこにあるんで。

[fana]

> 普通はライブラリ側で確保したメモリは、ライブラリ側で解放するように作る

ライブラリ側にこんなのを作ったりすると危険な感じということになりますか？
void LibFunc( std::vector<int> &V ){ V = { 1,2,3 }; }

[matukeso]

そもそもvectorとかstringとかはdebugなdefineで定義が変わったりするので、abiとしてNG。

[fana]

各位に感謝いたします．
私の無知のおかげ(!?)で

> デバッグビルドとリリースビルドで共通して使える .lib ファイル

を　作成する　際において注意すべき事柄（の１つ）が見えてきたようにも思えます．

[YUKI_DAYO]

皆さんの議論（？）をまとめると、

- 静的ライブラリにはリリースビルド用もデバッグビルド用も存在する。
- ただし、一般に公開されている .lib ファイルはリリースビルド用である。（なぜならそのライブラリをデバッグすることはないから）
- .lib ファイルの中の処理で `_DEBUG` 等のプリプロセッサに依存する場合や、`-O2` 等のコンパイルフラグに依存する場合は .lib ファイル内で完結しなければならない。（例えば .lib 内で new したものは .lib の処理で delete する等）
- 私は一般に公開されている .lib ファイルの処理は .dll によって場合分けされていると思っていたが、上記の通り、基本的に公開されている .lib ファイルはリリースビルド用なので、.lib ファイルと .dll ファイルにビルドタイプによる関係はない。

ということでしょうか？