5

私は 2 つの "プラグイン" (議論のためにソフトウェア パッケージ内の 2 つの異なるアプリケーションと考えてください) を持っており、ライブラリの 2 つの別々にビルドされたバージョンに動的にリンクしています。私のコードは C++ で書かれており、一貫した名前空間を使用しています。場合によっては、アプリケーションごとに 2 つの異なるバージョンをビルドする必要があります。これにより、パッケージ内の両方のアプリケーション (プラグイン) が同時に読み込まれると、いくつかの問題が発生するようです。まず、このエラーが発生する理由を理解するのに助けが必要です。

例として、私は2つの別々の同じ名前のライブラリ、たとえばmylib.so(またはDLL)を持っており、各アプリケーションはこれらの(一意の)1つにリンクしています。の基礎となるコードmylib.soが同じである場合 (つまり、名前空間、関数の名前など、もちろん実装がわずかに異なる場合)、これは問題を引き起こしますか? ライブラリの 2 つのコピーが一意の場所に配置されているという事実は、あいまいさやその他のリンク エラーが原因で発生する可能性のある問題を回避するのに十分ではないでしょうか? 私は明らかにそうではないと思います..しかし、これについて専門家から聞きたいです。

上記の説明が問題の原因であると仮定すると、ライブラリの名前を変更していくつかのバージョン情報を含めたり、あいまいなエラー (基になる関数/名前空間の名前がまだ同一である) に対する保護mylib_v1.soを提供したりするだけでしょうか? mylib_v2.so私はまだそうではないと思います..しかし、今回は確信が持てません。私が正しいと仮定すると、私のコードでいくつかのマクロを使用して名前空間を変更し、名前空間にバージョン情報を含める (たとえば、にnamespace mystuff {}変更するnamespace mystuff_v1) と、少なくともトリックは実行されますか? あなたの洞察に感謝します。

注: 驚くべきことに、あいまいさは Windows でのみ発生します。Linux は、2 番目の段落の状況を問題なく処理できます。

4

1 に答える 1

2

アプリケーションが1つだけを一意に使用していて、PATHとLD_LIBRARY_PATHが一致しないように設定されている場合、衝突は発生しません。マイクロソフトがそれを整理するまで、一度アプリケーションと一緒に配布された何百もの同様のmsvcrt.dllファイルでそれを見ることができます。

しかし、それでも、(わずかに異なる)コードがグローバルリソースを作成または参照する可能性があり、ここで衝突が発生する可能性があります。確かに、Windowsバリアントはグローバルに名前が付けられたものを使用せず、ここでさまざまなデータ構造を導入しますか?(標準設定、共有メモリなどを保存するファイル)。このグローバルなものはほとんどシステムに依存しているので-多分あなたはLinuxではやらないことをWindowsでやるでしょう...

于 2012-04-25T18:01:18.143 に答える