現在VC++2010においてlibvorbis_static.libを用いたMFCプログラムを書いているのですが、このライブラリが作成されたときにVC標準ライブラリが静的リンクされており、libvorbis_static.libを静的リンクする側のMFCプログラム側でMFCライブラリのリンク方法が静的になっていると、_mallocや_free関数がすでに定義されているというリンクエラーになり、競合状態となります。
Webで検索するとlibcmtd.libを無視する設定にするとよいなどとあるのですが、これを行うと以下のようなエラーが出てしまいます。
1>uafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___wargv
1>uafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argc
自身が作成しているプロジェクトのMFCライブラリリンク方法をDLLにすればこの問題は起こらなくなるのですが、MFCを静的リンクで使いたい場合にはどのようにしてこの競合を解決すればよいでしょうか？
libogg や libvorbis の distribution archive 中にある vcxproj ファイルを見ると
libvorbis_static の意味は libogg と libvorbis を static リンクする
libvorbis_dynamic は同様 libogg libvorbis を dynamic リンクする
という意味に限られているようだ。
C のライブラリに関しては常に dynamic リンクが指定されている。
(両者ともコンパイルオプション -MD マルチスレッド DLL となっている)
一方で MFC を static リンク指定すると (VS2010 は手元に無いので 2005 でのみ確認)
コンパイルオプションは -MT マルチスレッド (static) になる。
ひとつの EXE を構成する上で -MT と -MD が混在すると提示のとおりエラーとなる。
で、どうすればよいか、だけど・・・
解１： static リンクをやめて dynamic に戻す
現在 MFC や C runtime の static リンクは推奨されていないはずで
例： MSDN ぢゃないけど
http://social.msdn.microsoft.com/Forums/ja-JP/vcexpressja/thread/18021085-c534-4ddc-b2fc-9124c61ab153
今回の案件では vs2010 だし SxS 系の問題はないはず。
解２： ogg, vorbis ともに -MT で自前 build し自分で責任持つ
責任を持つとは、動作確認やセキュリティアップデートや何もかも、ということ。
libogg や libvorbis に脆弱性が見つかったら (static リンクしているのだから)
自作 EXE も更新する責任が生じるわけだけど、それも持つってことで。
くらいかな・・・
たしかに２０１０だとMFCをDLLで用いるという選択肢が無難なようです。
ありがとうございました。