以前、ライブラリ自体をUNICODEでビルドするとエラーが出まくるので、仕方なくライブラリのソースファイルに手をいれました。今回バージョンもUNICODEでビルドを通すように修正しなくては！と思いました。
しかし、ライブラリを利用するだけならそもそもそんなことしなくてもいいのではないかと思い、ライブラリについているサンプルのみをUNICODEでビルドしてみたところ、下記のエラーが出ます。
sample_dlg.obj : error LNK2019: 未解決の外部シンボル "public: thiscall win32::gui::dialog::dialog(class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > const &,enum win32::gui::dialog::create_subdialogs_type)" (??0dialog@gui@win32@@QAE@ABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@W4create_subdialogs_type@012@@Z) が関数 "public: thiscall win32::gui::detail::derive_from_base<struct win32::gui::dialog,0>::derive_from_base<struct win32::gui::dialog,0>(void)" (??0?$derive_from_base@Udialog@gui@win32@@$0A@@detail@gui@win32@@QAE@XZ) で参照されました。メンバテンプレートのインスタンス化に関するエラーのようですね。
Debug/sample_start.exe : fatal error LNK1120: 外部参照 1 が未解決です。
おそらくライブラリはマルチバイトでコンパイルしているためにbasic_stringのchar traitsはcharとなり、UNICODEバージョンのbasic_stringのインスタンス化されたobjがライブラリ側で生成されないためでしょう。
回避策としては、
・ライブラリをstatic linkするのをやめ、ソースも含めてプロジェクトをビルドする
・ライブラリをUNICODEでビルドしなおす(いままでどおり？)
ということが考えられます。
どっちが簡単なのか悩んでいるところです。