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

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

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

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

21
c dynamic-linking gcc linux shared-libraries

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. IMO, лучше всего использовать nether DT_RPATH не DT_RUNPATH отправлен в двоичные файлы.

если

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

17

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

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

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

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

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

более подробную информацию можно найти в "как писать разделяемые библиотеки" работа написано Ульрих Drepper.

4