2016-10-20 2 views
1

私は静的なライブラリLを生成するプロジェクトを持っています.Lのいくつかの関数はいくつかのpluggins Mをロードする能力を持っています(dlopen("libmmmm.so"):Mは共有lib 。autotoos/libtoolでのプラグイン(モジュール)の適切な扱い

Lの関数module_load()をテストするテストTは、メインテストT(Lが統計的にリンクされている)とプラグインMで構成され、T + Lの負荷をテストします。

テストはインストールの一部です(testdirが定義されています)。ここで

がテストTのディレクトリ(TとMの両方を構築する)にMakefile.amを以下のとおり

#the test program linked with the static lib L: 
#(the tests are distributed as well, hence the test_* prefix)         
test_PROGRAMS = tttt          
tttt_SOURCES = tttt.c 
tttt_LDADD = llll.la 

#the module to be loaded by the T+L test:              
lib_LTLIBRARIES = libmmmm.la           
libmmmm_la_SOURCES = mmmm.c         
libmmmm_la_LDFLAGS = $(AM_LDFLAGS) -module -shared 

問題はモジュールを見つけることができるのパスについてされています( テスト作品を、すなわちlibmmmm .soが見つかりました)を確認します。しかし、ツリー外(VPATH)ビルド(共有ライブラリが見つかりません)で失敗します。

質問: どのように動作するはずですか? libtoolはLD_LIBRARY_PATHのようなものを設定する必要があります。dlopen()*.laラッパーを理解できません。

これは何を行い、どのようにしてこれを修正することができますか?ビルドする、distcheckする... .libsディレクトリへの検索パスをハードコーディングすることは、あまり移植性がありません。多くの異なるプラットフォームをターゲットにしているので、autotoolsを使用します。

PS:私はMの「LIB」接頭辞が原因あなたはそれの世話をするためにlibltdlを使用することができ、「-module」オプション

+0

@ディエゴのアドバイスは道のりです。あなたのソフトウェアが 'libtool'でビルドされている場合、' libltdl'はGPLに支配されません。移植性があり、特定のプラットフォームで提供されていない場合は機能をエミュレートしようとします。モジュールは[automake'](http://www.gnu.org/software/automake/manual/automake.html#Libtool-Modules)マニュアルで簡単に触れられています。 'automake'と' libltdl'のより詳細な概要は、['libtool'](http://www.gnu.org/software/libtool/manual/libtool.html#Using-libltdl)マニュアルにあります。 –

答えて

2

に省略することができることを認識しています、1つは.laファイルを理解して、それはローディングを修正しますが、100%同じAPIではありません。

この状況では、独自のラッパースクリプトを作成してLD_LIBRARY_PATHを設定する必要があります。

+0

実際には@ Diegoのアドバイスにはまだ問題があります:ライブラリLをリンクするときに "lt__PROGRAM__LTX_preloaded_symbols 'への未定義の参照があります:autoolsはLをリンクするときに既に-dlopenオプションについて知りたいと思うようです。しかし、テストTだけがそれを知っています!ですから、tttt_LDAD行に "-dlopen mmmm.la"オプションがあります.LIBをビルドするときにlibltdlを使用できますか? (すなわち、ロードされるモジュールが分かる前に)。 – user1159290

+0

しかし、ldlのlibにlt_libltdl_LTX_preloaded_symbolsというシンボルがあります。これはlt__PROGRAM__LTX_preloaded_symbolsと同じであるはずですか? – user1159290

関連する問題