2016-10-20 1 views
1

J'ai un projet qui génère une librairie statique L. Une fonction de L a la capacité de charger quelques plugins M (en utilisant dlopen("libmmmm.so"): M est un lib (module) partagé) . Le test T testant la fonction module_load() de L est constitué du test principal T (auquel L est lié statiquement) et d'un plugin M, pour tester son chargement en T + L.bonne gestion des plugins (modules) dans autotoos/libtool

Les tests font partie de l'installation (testdir est défini).

suit Ici, le Makefile.am dans le répertoire de test de T (bâtiment à la fois T et M):

#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 

Le problème est au sujet de la voie à laquelle se trouve le module: Les travaux d'essai (c.-à-libmmmm .so est trouvé) pour faire vérifier. Mais échoue pour les constructions hors arbre (VPATH) (lib partagé non trouvé).

Donc la question: Comment est-ce censé fonctionner? libtool doit mettre quelque chose comme LD_LIBRARY_PATH, je suppose, que dlopen() ne comprendra jamais l'emballage *.la ...

Alors, que fait-il et comment puis-je résoudre ce problème il fonctionne en tout temps, à savoir faire vérifier, sur l'arbre build, make distcheck ... Codage dur d'un chemin de recherche dans le répertoire .libs ne se sent pas très portable: Nous utilisons autotools car nous ciblons de nombreuses plates-formes différentes.

PS: Je suis conscient du fait que le préfixe « lib » de M pourrait être omise en raison de l'option « -module »

+0

@ Le conseil de Diego est la voie à suivre. 'libltdl' n'est pas encombré par la GPL si votre logiciel est construit avec' libtool'. Il est portable et tente d'émuler les fonctionnalités s'il n'est pas fourni par une plate-forme spécifique. Les modules sont brièvement mentionnés dans le manuel ['automake'] (http://www.gnu.org/software/automake/manual/automake.html#Libtool-Modules). Un aperçu plus détaillé de 'automake' et' libltdl' se trouve dans le manuel ['libtool'] (http://www.gnu.org/software/libtool/manual/libtool.html#Using-libltdl). –

Répondre

2

Vous pouvez utiliser libltdl pour prendre soin d'elle, que l'on ne comprend .la fichiers et cela va corriger le chargement, mais ce n'est pas 100% la même API.

Je crains que sinon, vous devrez écrire vos propres scripts wrapper pour définir LD_LIBRARY_PATH dans cette situation.

+0

en fait encore problème avec le conseil de @ Diego: Got: "référence non définie à' lt__PROGRAM__LTX_preloaded_symbols '"lors de la liaison bibliothèque L. Il semble que les autools veulent déjà connaître l'option -dlopen lors de la liaison L! Mais seul le test T le sait! donc j'ai maintenant l'option "-dlopen mmmm.la" sur la ligne tttt_LDAD ... Est-ce que libltdl peut être utilisé lors de la construction d'un LIB? (c'est-à-dire avant que le module à charger soit connu). – user1159290

+0

Mais la bibliothèque ldl a un symbole appelé lt_libltdl_LTX_preloaded_symbols ... Est-ce censé être le même que lt__PROGRAM__LTX_preloaded_symbols ??? – user1159290