1

システムの C ランタイム ライブラリへの将来の更新の影響を受けないように、ライブラリ (静的ライブラリまたは dll/so) をどのように構築しますか?

7 月末、Microsoftは C ランタイム ライブラリを含む一連のライブラリを更新しました。私たちのアプリは、MFC/C++/VB といくつかのサード パーティ製ライブラリ (クローズド ソースを含む) を組み合わせて作成されています。

ソースを持っているすべてのライブラリを再コンパイルするのに忙しくしていますが、それが本当に必要なのだろうか? 以前のバージョンの C ランタイムに対してビルドされたライブラリをリンクまたはロードするとどうなりますか?

このようなものを再コンパイルするとき、メイン アプリケーションとサポート ライブラリの間でどのコンパイラとリンカーの設定を同じにする必要がありますか? ランタイム ライブラリの設定は同じにする必要があることがわかりました (マルチスレッド バージョンの /MD と /MDd を使用しています) が、他の設定が心配です。私は実際にすべての設定を Visual Studio のプロパティ シートに引き出し、さまざまなプロジェクトすべてに同じシートを使用していますが、これはサード パーティのライブラリでは機能せず、やり過ぎだと考えています。

リンカーが競合するライブラリに関する警告を吐き出すことに気付きましたが、デフォルトのライブラリを無視することを提案しています。そうしても安全ですか？問題に対する非常に醜い解決策のようです。

4

2 に答える 2

1

あなたまたはあなたのサードパーティ コンポーネントが古い C ライブラリに対して静的にリンクしている場合は問題ありません。これらのライブラリをアップグレードしても、プログラムには影響しません。もちろん、バグ修正やパフォーマンスのアップグレード、または何を持っているかの恩恵を受けることはありません. 新しい設定を利用するためにコードを再コンパイルする場合は、すべてのランタイム スイッチを同じにする必要があります。ライブラリがコンパイルされるタイミングや理由に関係なく、これは常に当てはまります。デフォルトのライブラリを無視することはおそらく安全です (私は何年も問題なくそうしてきました)。

動的にリンクされたライブラリは別の話です。特定の dll の特定のバージョンを持つターゲット システムに依存し、代わりに互換性のない他のバージョンがある場合、問題が発生します。この問題に対する従来の解決策は、必要なすべての dll を実行可能ファイルにバンドルすることです。Microsoft の新しいサイド バイ サイド アセンブリも役立つかもしれませんが、セットアップが少し難しすぎて、気にすることができませんでした。運が良くなるかもしれません。

于 2009-09-01T15:05:59.723 に答える
1

サード パーティのライブラリを DLL としてロードしている場合、実行可能ファイルとは異なるランタイム バージョンに依存している可能性があります。

  • ランタイム ライブラリに依存する型のパラメーターを引き渡していない (STL 型など)
  • サードパーティのライブラリは、ランタイムのバージョンをロードできます。これは、ランタイムでビルドされているか、ランタイムに静的にリンクされています

したがって、DLL を再コンパイルする必要はありません。

ライブラリに静的にリンクしている場合、またはランタイム DLL で定義された型を渡す場合は、ライブラリに既にインポートされているシンボルに問題が発生する可能性があるため、再コンパイルする必要がある可能性が高くなります。

于 2009-09-01T17:26:34.763 に答える