Использовать 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?

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

Источник

3 ответа

Решение

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

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

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

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

если

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

Источник

Ответ Чилла совершенно правильный; Я хотел просто добавить немного цвета из недавнего чтения источника 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. Готово, "не найдено".
Источник

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

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

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

Источник
Другие вопросы по тегам