Правильное использование rpath (относительный или абсолютный)
При создании двоичного файла или библиотеки, указав rpathт.е.
-Wl,rpath,<path/to/lib>
сообщает компоновщику, где найти требуемую библиотеку во время выполнения двоичного файла.
Какова философия UNIX относительно абсолютных и относительных путей здесь? Лучше использовать абсолютный путь, чтобы найти библиотеку отовсюду? Или лучше сделать его относительным, чтобы при копировании всего каталога или переименовании пути более высокого уровня двоичный файл не использовался?
Обновить
С помощью $ORIGIN обычно является предпочтительным способом построения двоичных файлов. Для библиотек я хотел бы указать абсолютный путь, потому что иначе вы не сможете связываться с библиотекой. Символическая ссылка изменит $ORIGIN указывать путь ссылки, а не цели ссылки.
3 ответа
Какова философия UNIX относительно абсолютных и относительных путей здесь?
Использование относительного пути делает исполняемый файл, который работает только при вызове из определенного каталога, что почти никогда не то, что вы хотите. Например, если исполняемый файл находится в /app/foo/bin/exe и имеет DT_RUNPATH из lib/и зависимая библиотека находится в /app/foo/lib/libfoo.soтогда exe будет работать только при вызове из /app/foo, а не при вызове из любого другого каталога.
Использование абсолютного пути намного лучше: вы можете сделать cd /tmp; /app/foo/bin/exe и исполняемый файл все еще работает. Тем не менее, это все же далеко не идеально: вы не можете легко иметь несколько версий бинарного файла (это важно во время разработки), и вы диктуете конечным пользователям, где они должны установить пакет.
В системах, которые поддерживают $ORIGIN, с помощью DT_RUNPATH из $ORIGIN/../lib даст вам исполняемый файл, который работает при установке в любом месте и вызывается из любого каталога, при условии, что относительные пути к bin/ а также lib/ сохранены
В случае rpath, нет смысла использовать относительный путь, так как относительный путь будет относительно текущего рабочего каталога, а НЕ относительно каталога, в котором был найден двоичный файл / библиотека. Так что это просто не будет работать для исполняемых файлов, найденных в $PATH или библиотеки в большинстве случаев.
Вместо этого вы можете использовать $ORIGIN "специальный" путь, чтобы иметь путь относительно исполняемого файла с-Wl,-rpath,'$ORIGIN' - обратите внимание, что вам нужны кавычки вокруг него, чтобы оболочка не интерпретировала его как переменную, и если вы пытаетесь сделать это в Makefile, вам нужно $$ чтобы не делать интерпретировать $ также.
Из интерфейса программирования Linux:
Использование $ORIGIN в rpath
Предположим, мы хотим распространять приложение, которое использует некоторые из своих собственных общих библиотек, но не хотим требовать от пользователя установки библиотек в один из стандартных каталогов. Вместо этого мы хотели бы позволить пользователю распаковать приложение в произвольный каталог по своему выбору, а затем сразу же запустить приложение. Проблема в том, что приложение не может определить, где находятся его разделяемые библиотеки, если только оно не попросит пользователя установить
LD_LIBRARY_PATHили мы требуем, чтобы пользователь запустил какой-то сценарий установки, который идентифицирует необходимые каталоги. Ни один из этих подходов не является желательным. Чтобы обойти эту проблему, динамический компоновщик понимает специальную строку,$ORIGIN(или, что то же самое,${ORIGIN}), вrpathСпецификация. Динамический компоновщик интерпретирует эту строку как «каталог, содержащий приложение». Это означает, что мы можем, например, создать приложение с помощью следующей команды:
$ gcc -Wl,-rpath,'$ORIGIN'/lib ...Это предполагает, что во время выполнения общие библиотеки приложения будут находиться в подкаталоге lib в каталоге, содержащем исполняемый файл приложения. Затем мы можем предоставить пользователю простой установочный пакет, содержащий приложение и связанные библиотеки, и пользователь может установить пакет в любом месте, а затем запустить приложение (т. е. так называемое «приложение под ключ»).