Как запретить libtool добавлять системный путь (т.е. / usr / lib) в RUNPATH (rpath)?

Question

Как запретить libtool добавлять системный путь (то есть / usr / lib) в RUNPATH (rpath)?

Во время тестирования (проверки) MPFR libtool добавляет системный путь к rpath перед тестовым путем, то есть:

0x000000000000001d (RUNPATH) Путь к библиотеке: [/usr/lib:/LFSC/native/src/bmpfr/src/.libs]

В результате тесты могут запускать установленные библиотеки (в первом путь (система)) вместо тестирования. Обычно это происходит при переустановке программного обеспечения. Возможно, это влияет на установку обновлений.

Это происходит из-за существующего файла .la зависимости, например, libquadmath.la

Удаление .la файлов решает эту проблему.

Но есть нет никаких причин добавлять системный путь в жестко запрограммированную RUNPATH.

Есть ли способ решить эту проблему, не удаляя файлы .la? Конечно, я знаю, что могу изменить сгенерированный скрипт libtool.

---

Речь идет о жестко заданном пути выполнения в файле ELF, который имеет высокий приоритет по отношению к системному пути и LD_LIBRARY_PATH. Вы можете легко понять это, скомпилировав MPFR из исходного кода без установки. После make check запустите это в исходной папке root: readelf -a tests/tversion | grep PATH Вы увидите RPATH без системного пути. Затем добавьте libquadmath.la в g cc lib home, например, / usr / lib / gcc / x86_64- linux -gnu / 6 / удалить тесты и повторите проверку, затем снова проверьте PATH в версии

# libquadmath.la - a libtool library file
# Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libquadmath.so.0'

# Names of this library.
library_names='libquadmath.so.0.0.0 libquadmath.so.0 libquadmath.so'

# The name of the static archive.
old_library='libquadmath.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=' -lm'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libquadmath.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/lib/../lib'

Answer 1

Но нет никакой причины добавлять системный путь в жестко запрограммированную RUNPATH.

Не так. Большинство систем имеют несколько каталогов в пути поиска библиотеки по умолчанию, и фактически путь поиска иногда изменяется при установке или удалении программного обеспечения. Помещение каталога (-ies), в котором указанная системная библиотека фактически находилась во время соединения, в RUNPATH для данного двоичного файла делает этот двоичный файл более устойчивым к динамическому связыванию какой-либо другой библиотеки с тем же именем во время выполнения. Это также может немного ускорить динамическое связывание c.

Более того, RUNPATH двоичного файла имеет меньший приоритет при динамическом связывании c, чем переменная окружения LD_LIBRARY_PATH, поэтому вы можете переопределить RUNPATH во время выполнения в ситуациях такой как тот, который вы описываете. В этом весь смысл наличия RUNPATH в дополнение к RPATH, который имеет более высокий приоритет, чем LD_LIBRARY_PATH.

Во время тестирования (проверки) MPFR libtool добавляет систему путь к rpath до пути тестирования, то есть:

0x000000000000001d (RUNPATH) Путь к библиотеке: [/usr/lib:/LFSC/native/src/bmpfr/src/.libs]

Полагаю, вы имеете в виду, что система сборки помещает такие записи в программы и библиотеки, которые встроены в дерево сборки. Libtool обычно изменяет записи пути выполнения, когда работает в режиме (переустановки) (который частично зависит от файлов .la). Не следует ожидать появления каталогов дерева компоновки в пути выполнения программы или библиотеки после того, как они правильно установлены в системе.

Обратите также внимание, что это RUNPATH, а не RPATH. Как упоминалось выше, это не одно и то же.

В результате тесты могут запускать установленные библиотеки (по первому пути (системе)) вместо тестовых. Обычно это происходит при переустановке программного обеспечения. Возможно, это влияет на установку обновлений.

Если это происходит, когда вы запускаете make check или когда вы запускаете программы через libtool, работающие в режиме «execute», то вам следует поднять проблему с MPFR о Это. Это не проблема, если это происходит только при непосредственном запуске неустановленных тестовых программ (но см. Также ниже).

Есть ли способ решить эту проблему без удаления .la файлы?

Вообще говоря, следует ожидать установки LD_LIBRARY_PATH для запуска неустановленных программ или динамического связывания с неустановленными библиотеками. make check должен автоматически принять соответствующие меры, и в системе сборки, которая использует libtool, это может принять форму запуска двоичных файлов через libtool. Как правило, система сборки на основе Autotools фактически создает сценарии-оболочки для встроенных двоичных файлов, чтобы сделать это максимально прозрачным.

При этом удаление файлов .la не обязательно является необоснованным. У Libtool есть веские причины для их создания, но остаточная выгода от их установки в системе вместе с самими библиотеками может не компенсировать недостатки. RedHat, например, долгое время придерживался мнения, что этого не происходит, поэтому фактически он не включает файлы .la в свои пакеты RPM, и в его рекомендациях по упаковке указано, что сторонние упаковщики также не должны этого делать.

В конечном итоге, если вы хотите сохранить внешние файлы .la неизмененными, но избегать libtool извлечения из них записей RUNPATH при связывании, тогда ваша основная альтернатива - изменить сценарий libtool проекта. Детали в значительной степени зависят от того, какую версию libtool использует проект.