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

Question

Эта страница - 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 kind-of отменяет RPATH, поэтомукосвенная динамическая загрузка не работает должным образом?Но почему тогда RPATH устарел в пользу RUNPATH?

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

Answer 1

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

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

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

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

если

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

Answer 2

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

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

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

Answer 3

Но почему тогда RPATH обесценились в пользу RUNPATH?

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

Более подробную информацию можно найти в «Как писать совместно используемые библиотеки» , написанном Ульрихом Дреппером .