1

コードに最小限の変更を加えて、プログラムとそのプラグインをカスタムMakefileからCMakeに変換しようとしています。

プラグインとアプリの両方がいくつかのコードを共有しています。#ifdef ... #else ... #endifブロックは違いがある場合に使用され、コードは正しい定義でコンパイルされていると確信しています。共有コードには、ToolImageというクラスが含まれています。コードがアプリ用にコンパイルされる場合、ToolImageコンストラクターはプラグイン用にコンパイルされる場合とは異なるリソースパスを使用します。

#ifdef THE_APP
 ToolImage::ToolImage(const wxString& name, bool full_path_given):wxImage(full_path_given?name:
 (wxGetApp().GetResFolder() + _T("/bitmaps/") + name + _T(".png")), wxBITMAP_TYPE_PNG)
#else
 ToolImage::ToolImage(const wxString& name, bool full_path_given):wxImage(full_path_given?name:
 (theApp.GetResFolder() + _T("/bitmaps/") + name + _T(".png")), wxBITMAP_TYPE_PNG)
#endif
{
 ...
}

プログラムとそのプラグインがカスタムMakefileでコンパイルされると、すべてが期待どおりに機能します。私が作成した一連のCMakeLists.txtファイルを使用して両方をCMakeでコンパイルすると、問題が発生します。プラグインがツールバーのビットマップを読み込めないということです。

ToolImageクラスまで問題を追跡しました。gdbで指定された行番号は、プラグインが間違ったコンストラクターを使用していることを示しています。straceは同じことを教えてくれます（プラグインはプラグインのリソースディレクトリではなく、アプリのリソースディレクトリでビットマップを探しています）。定義が台無しになっていないことを確認するために、ツール用にのみコンパイルする必要がある#ifdefの部分の中に#errorをToolImage.cppに配置しましたが、プラグインはエラーなしでコンパイルされました。これは、プラグインが正しいコードでコンパイルされていることを示しています。間違ったパスを使用しているため、プログラムにコンパイルされたクラスとコンストラクターを独自のパスではなく使用していると思います。

プラグインがアプリ内のクラスではなく独自のToolImageクラスを使用するようにするにはどうすればよいですか？！私はプロジェクトを所有しておらず、異なるビルドシステムでのビルドをサポートするためだけに大規模な変更を加えたくありません。

プリコンパイラを使用してクラスの2つのバージョンを作成することは、私には悪い選択のように思えます。コードに変更を加える必要がある場合、回避策の提案はありますか？

4

2 に答える 2

0

実験のために、アプリをビルドするときに、すべてまたは特定のソースに-fvisibility=hiddenを追加します。これにより、プラグインからアプリケーションのToolImageが非表示になります。

多くの場合、プラグインはメインの実行可能ファイルとは異なるシンボルを使用するため、これは普遍的な方法ではありません。

于 2011-02-06T01:57:28.477 に答える
0

CMakeLists.txtにリンカーフラグ-Wl、-Bsymbolic-functionsを追加することで、これを修正しました。

set_target_properties( heekscnc PROPERTIES LINK_FLAGS -Wl,-Bsymbolic-functions )
于 2011-08-05T13:24:07.077 に答える