Libtool связывает разделяемую библиотеку с статической библиотекой, заданной явным путем (без опции -l)
Я хочу вытащить все символы из статической библиотеки (libyaml-cpp) в общую, которую я создаю (libLHAPDF), чтобы избежать явной зависимости для пользователей последней. (Это не мой любимый способ сделать что-то, но сложность установки необходимого условия состояла в регулярном отрицательном отзыве о пакете.) Поэтому я пытаюсь собрать соответствующий бит моей разделяемой библиотеки с помощью правила automake, например:
libLHAPDFInfo_la_LDFLAGS = $(AM_LDFLAGS) \
$(srcdir)/yamlcpp/yaml-cpp/libyaml-cpp.a
Я специально хочу что-то подобное, а не
libLHAPDFInfo_la_LDFLAGS = -L$(srcdir)/yamlcpp/yaml-cpp -lyaml-cpp \
$(AM_LDFLAGS)
потому что в другом месте системы может быть установлена совместно используемая версия lib libyaml-cpp, и я не хочу ее использовать. (Порядок нечетного флага в этом последнем случае является попыткой убедиться, что -lyaml-cpp находит тот, который встроен в srcdir... и да, это действительно srcdir, а не builddir в этом случае!)
Тем не менее, первая версия дает предупреждение, которое я бы предпочел не иметь:
*** Warning: Linking the shared library libLHAPDFInfo.la against the
*** static library ./yamlcpp/yaml-cpp/libyaml-cpp.a is not portable!
и что более важно, он на самом деле не работает: если я запускаю nm в сгенерированной библиотеке, я вижу неопределенные символы:
$ nm src/.libs/libLHAPDFInfo.a | grep YAML
U _ZN11LHAPDF_YAML4NodeC1Ev
U _ZN11LHAPDF_YAML4NodeD1Ev
...
(Подробности: libLHAPDFInfo.a является записью noinst_LTLIBRARIES, используемой в качестве промежуточного звена для построения окончательной разделяемой библиотеки. Так что это даже не работает при связывании одной статической библиотеки с другой. И чтобы избежать столкновений символов, связанная версия слегка взломана для переименования пространство имен YAML для LHAPDF_YAML: это ничего не меняет, но я подумал, что упомяну это на тот случай, если эти имена символов покажутся вам странными.)
Если я использую вторую форму флагов ссылок (путь -lyaml-cpp), я получу все символы LHAPDF_YAML в libLHAPDFInfo.a и после этого в общей библиотеке. И больше нет никаких предупреждений о непереносимости связывания статической библиотеки (которая была построена с -fPIC, так что это допустимо). Но если в системе также найден общий libyaml-cpp, он используется независимо от порядка флагов -L/-l, чего я не хочу.
Любые предложения о том, как я могу убедиться, что будет использоваться версия библиотеки по определенному пути, при этом правильно копируя символы и избегая предупреждений libtool?
РЕДАКТИРОВАТЬ: сказав, что я мог бы получить символы, скопированные из libyaml-cpp.a в libLHAPDFInfo.a через флаг -lyaml-cpp, после нескольких итераций я больше не мог заставить этот подход показывать ожидаемые символы через nm. Если посмотреть на команды ar/ranlib, выполняемые libtool при создании libLHAPDFInfo.a, аргументы -l, похоже, полностью отброшены. Так что я не знаю, как это вообще работало... насколько я могу судить, это не тот режим, который поддерживает libtool, не тот, который задокументирован. В конце я переименовал libyaml-cpp в liblhapdf-yaml-cpp.a как часть сборки (так как ни одна библиотека с таким именем не должна быть случайно найдена), и связал ее с финальным общим libLHAPDF.so, а не со статической удобной библиотекой, Не так аккуратно, как мне бы хотелось - я надеялся изолировать всю обработку зависимостей yaml-cpp в сборке одной удобной библиотеки, и полагаться на копии файлов для устранения неоднозначности поиска в библиотеке неудовлетворительно - но это работает.