Q&A
「C言語何でも質問掲示板」とマルチポストであるように見受けるので，そこはちゃんと対応してください．
はじめましてこんばんは。
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
免責
初めての投稿ということで至らぬ点があるかと思いますが、優しく指摘していただけると嬉しいです。
申し訳ありませんでした。
対応しました。
例えば順番的にあっちに先に質問したのであれば，こっちに質問する際には素直にその理由を述べればよいと思う．
「実は別の箇所に質問したのですが，応答内容がイミフなのと出てきた相手の雰囲気があまりにもXXXなためにその方とやりとりを続けるのが精神的につらく…」とか何とか．
（それが正当な理由と見なされるかどうかという話は別途あるけども）
そうですね。
理由をちゃんと書けばよかったです。
実際にはあちらで回答を頂く前にこちらで同様の質問を投稿してしまったのですが…
理由はアクティブユーザー数の違いです。（あちらで他の質問を見ていると同じ人ばかり回答していた）
理由はともあれ掲示板に不慣れだったのが問題だったようです。
以後気を付けます。
本題とズレてしまいそうなのですが、
静的ライブラリと、インポートライブラリと、
どちらも.libですが、この２つについて混乱してないでしょうか？
インポートライブラリという単語を聞いたことがなかったので調べたところ、混同していることが判明しました。
もう少し調べてみます。
完全に混同していました。
調べた結果を報告します。
- インポートライブラリとは、動的ライブラリにおけるヘッダファイルのようなものである。
- 静的ライブラリとは、`.obj` ファイルを一つにまとめた（アーカイブした）ものである。
以上より推察。
- `d3d12.lib` 等の動的ライブラリとニコイチになっているものは基本的にインポートライブラリであると思われる。（この場合、`d3d12.lib` と `d3d12.dll`）
- インポートライブラリには基本的に実装がないため、デバッグビルドとリリースビルドで共用できる。
- 逆に静的ライブラリには実装が入っているため、デバッグビルドとリリースビルドで共用できるかどうかは実装依存。
参考文献
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1187019446
回答1件
0
debug-buildされたライブラリはその名の通りデバッグ用。なのでrelease時には不要な/余計なデータ/実行コードがみっちり詰め込まれています。
そんなのを本番(release版)でも使いたいんですか?
※ Linux(gcc/g++)なら、デバッグのために(-g オプションで)付加した情報をそぎ落とすことができますけどね。
https://linuxjm.osdn.jp/html/GNU_binutils/man1/strip.1.html
投稿2022/01/05 14:11
編集2022/01/05 14:18
総合スコア16614
回答ありがとうございます。
> しかし、.obj もしくは .o ファイルを作成する際に、-D_DEBUG や -DNDEBUG などのデバッグ用とリリース用で異なるプリプロセッサフラグを指定する場合があります。
> そうすると .obj ファイルから .lib ファイルを作成するときにデバッグもしくはリリース用で固定されてしまいます。
>
> そこで質問なのですが、これを回避し、デバッグビルドとリリースビルドで共通して使える .lib ファイルは作成できるのでしょうか？
と述べたように、デバッグビルドで生成された .lib ファイルをリリースビルドで使用する事を望んでいるわけではありません。（逆も然りです）
@episteme さんがおっしゃる通り、普通に .obj ファイルから .lib ファイルを作成すると .obj ファイルを作成したビルドタイプ専用になってしまいます。
ですが、例えば Win32 API でアプリケーションを作成する場合、デバッグビルドでもリリースビルドでもリンクする静的ライブラリファイルは同じですよね？（`gdi32.lib`など）
その仕組みを知りたいのです。
release用ライブラリをアプリのdebug用にリンクしてるだけじゃないかしら...
ライブラリのdebugをしたいわけじゃないから、ライブラリにはdebug情報要らんでしょ。ってことでは?
なるほど…
じゃあ静的ライブラリにデバッグ用なるものは存在しないということなんですかね。
基本的にアーカイブするオブジェクトファイルは stable ですし…
＞じゃあ静的ライブラリにデバッグ用なるものは存在しないということなんですかね。
んなこたーない。
あなたがライブラリを作ってて、
そいつをdebugしたいならdebug-buildし、
リリース時にはrelease-buildすればいい。
（無知な初心者の便乗質問になりますが）
ライブラリ側 と それを使う側 とで デバッグ/リリース が異なるとき，
例えば一方で new したものを他方で delete した際とかに異常事態になったりしないのでしょうか？
Debug版はコードとそれに対する機械語との対応表が追加されたもの(シンボリック・デバッグのため)であるはず原則的に。あとDebug版は(通常)オプティマイズを軽くします。
calling-conventionが変わると厄介でしょうね(呼べなく/帰れなくなるから)。
だからそれはないだろうし、やっちゃいけないんだろうと。
# そもそもdebug版ライブラリはコードも一緒に用意しないとシンボリック・デバッグできんしなぁ...
うーん，何だろう，良く分かってないですが，
lib側が使う C/C++ のランタイム(?) と libを用いるAPP側が使うランタイム とで デバッグ版/リリース版 が異なってしまう場合に，動作の不整合が起きたりしないのか？ っていう．
（new/delete みたいに 対になる物 はそういう話が特にありそうかな？と思ったので例に挙げた）
> fana
ヘッダオンリーライブラリでもなければ、普通はライブラリ側で確保したメモリは、ライブラリ側で解放するように作るんじゃないですかね。（COMオブジェクトのIUnknown::Release的なやつ）
リリース/デバッグ関係なしに、メモリアロケータが違った場合に死ぬので。
DLLがnewした領域はDLLでdeleteせんとコケたりしますね。メモリ空間がEXEと異なるとこにあるんで。
> 普通はライブラリ側で確保したメモリは、ライブラリ側で解放するように作る
ライブラリ側にこんなのを作ったりすると危険な感じということになりますか？
void LibFunc( std::vector<int> &V ){ V = { 1,2,3 }; }
そもそもvectorとかstringとかはdebugなdefineで定義が変わったりするので、abiとしてNG。
各位に感謝いたします．
私の無知のおかげ(!?)で
> デバッグビルドとリリースビルドで共通して使える .lib ファイル
を 作成する 際において注意すべき事柄（の１つ）が見えてきたようにも思えます．
皆さんの議論（？）をまとめると、
- 静的ライブラリにはリリースビルド用もデバッグビルド用も存在する。
- ただし、一般に公開されている .lib ファイルはリリースビルド用である。（なぜならそのライブラリをデバッグすることはないから）
- .lib ファイルの中の処理で `_DEBUG` 等のプリプロセッサに依存する場合や、`-O2` 等のコンパイルフラグに依存する場合は .lib ファイル内で完結しなければならない。（例えば .lib 内で new したものは .lib の処理で delete する等）
- 私は一般に公開されている .lib ファイルの処理は .dll によって場合分けされていると思っていたが、上記の通り、基本的に公開されている .lib ファイルはリリースビルド用なので、.lib ファイルと .dll ファイルにビルドタイプによる関係はない。
ということでしょうか？
あなたの回答
tips
プレビュー
