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

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

Тест T, проверяющий функцию module_load() L, состоит из основного теста T (с которым L статически связан) и плагина M для проверки его загрузки в T+L.

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

Далее следует Makefile.am в тестовом каталоге T (сборка 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) для проверки make. Но не работает для сборок вне дерева (VPATH) (общая библиотека не найдена).

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

Итак, что он делает и как я могу исправить это, чтобы он работал всегда, т. е. make check, out of tree build, make distcheck... Жесткое кодирование пути поиска в каталоге .libs не кажется очень переносимым: мы используем автоинструменты, потому что мы ориентируемся на множество различных платформ.

PS: я знаю, что префикс "lib" M может быть опущен из-за опции "-module"


autotools shared-libraries libtool
person user1159290    schedule 20.10.2016    source источник
comment
Совет @Диего - правильный путь. libltdl не обременяется GPL, если ваше программное обеспечение создано с libtool. Он портативный и пытается эмулировать функциональность, если она не предусмотрена конкретной платформой. Модули кратко упоминаются в руководстве automake. Более подробный обзор automake и libltdl можно найти в libtool< /а> руководство.   -  person Brett Hale    schedule 21.10.2016

Ответы (1)


arrow_upward
2
arrow_downward

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

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

person Diego Elio Pettenò    schedule 21.10.2016
comment
на самом деле все еще проблема с советом @Diego: Получил: неопределенная ссылка на `lt__PROGRAM__LTX_preloaded_symbols' при связывании библиотеки L. Похоже, что autools хочет знать об опции -dlopen уже при связывании L! Но это знает только тест T! так что теперь у меня есть опция -dlopen mmmm.la в строке tttt_LDAD... Можно ли использовать libltdl при построении LIB? (т.е. до того, как будет известен загружаемый модуль). - person user1159290; 24.10.2016
comment
Но в ldl lib есть символ с именем lt_libltdl_LTX_preloaded_symbols... Это должно быть таким же, как lt__PROGRAM__LTX_preloaded_symbols??? - person user1159290; 24.10.2016