Использовать RPATH, но не RUNPATH?

Эта страница - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - говорит о порядке поиска библиотеки в ld.so:

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs

И затем предложите:

Когда вы отправляете двоичные файлы, используйте RPATH, а не RUNPATH, или убедитесь, что LD_LIBRARY_PATH устанавливается до их запуска.

Итак, использование RPATH с RUNPATH плохо, потому что RUNPATH отменяет отмену RPATH, так что непрямая динамическая загрузка не работает должным образом? Но почему тогда RPATH устарел в пользу RUNPATH?

Может кто-нибудь объяснить ситуацию?

ОТВЕТЫ

Ответ 1

Когда вы отправляете бинарный файл, хорошо бы предоставить пользователям возможность приспособить бинарный файл к специфике их собственной системы, в том числе путем настройки путей поиска в библиотеке.

Пользователь обычно может настроить LD_LIBRARY_PATH и /etc/ld.so.conf, оба из которых имеют более низкий приоритет, чем DT_RPATH, то есть вы не можете переопределить то, что жестко закодировано в двоичном /etc/ld.so.conf, тогда как если вы используете DT_RUNPATH вместо этого, пользователь может переопределить это с LD_LIBRARY_PATH.

(FWIW, я думаю, что ld.so.conf также должен иметь приоритет над DT_RUNPATH, но, во всяком случае, по крайней мере, у нас есть LD_LIBRARY_PATH).

Кроме того, я категорически не согласен с предложением выше использовать DT_RPATH. IMO, лучше всего использовать DT_RPATH не в DT_RUNPATH в поставляемых двоичных файлах.

если

вы поставляете все зависимые библиотеки с вашими исполняемыми файлами и хотите убедиться, что JustWork (tm) после установки, в этом случае использует DT_RPATH.

Ответ 2

Ответ на холод в точности правильный; Я хотел просто добавить некоторый цвет из недавнего чтения источника glibc ([master 8b0ccb2], в 2.17). Чтобы быть ясным, если библиотека не найдена в местоположении, заданном данным уровнем, будет проверен следующий уровень. Если библиотека найдена на заданном уровне, поиск останавливается.

Порядок поиска динамической библиотеки:

  • DT_RPATH в двоичном формате ELF, если DT_RUNPATH не установлен.
  • Записи LD_LIBRARY_PATH, если setuid/setgid
  • DT_RUNPATH в двоичном формате ELF
  • /etc/ld.so.cache, если только -z nodeflib указан во время соединения
  • /lib,/usr/lib, если только -z nodeflib
  • Готово, "не найдено".

Ответ 3

Но почему тогда RPATH устарел в пользу RUNPATH?

Когда DT_RPATH был введен, он имел приоритет над всеми другими параметрами. Это сделало невозможным переопределение пути поиска библиотек даже для целей разработки. Поэтому был введен еще один параметр LD_RUNPATH, который имеет более низкий приоритет, чем LD_LIBRARY_PATH.

Более подробную информацию можно найти в "Как написать общие библиотеки" , написанной Ulrich Drepper.