правильная обработка плагинов (модулей) в autotoos/libtool

Question

У меня есть проект, который генерирует статический lib L. Некоторая функция L имеет возможность загружать некоторые pluggins M (используя dlopen("libmmmm.so"): M - это общий lib (модуль)). ,

Испытание Т-теста module_load() Функция L производится из основного теста T (к которому L связана статически) и pluggin M, чтобы проверить его загрузку в T + L.

Испытания являются частью установки (определен testdir).

Здесь следует Makefile.am в каталоге испытаний Т в (здание как T и 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 

Задача о пути, на котором модуль может быть найден: Тест работает (т.е. libmmmm .so найдено) для проверки. Но не получается из сборки дерева (VPATH) (общий lib не найден).

Итак, вопрос: Как это должно работать? Libtool должен установить что-то вроде LD_LIBRARY_PATH, я думаю, так как dlopen() никогда не понять *.la обертку ...

Так что же делать и как я могу это исправить, так что работает все время, то есть произвести проверку, из дерева build, make distcheck ... Жесткое кодирование пути поиска в каталоге .libs не очень переносимо: мы используем autotools, потому что мы нацелены на разные платформы.

PS: Я знаю, что «Lib» префикс M может быть опущен из-за «-модуле» вариант

Answer 1

Вы могли бы использовать libltdl, чтобы заботиться о нем, что один делает понять .la файлы, и который исправит загрузку, но это не 100% тот же API.

Боюсь, что в противном случае вам придется написать свои собственные сценарии-обертки, чтобы установить LD_LIBRARY_PATH в этой ситуации.