Использование -rpath и $ ORIGIN с проектами на основе libtool? - PullRequest
Новая
       8

Использование -rpath и $ ORIGIN с проектами на основе libtool?

4 голосов
/ 03 июня 2011

Я пытаюсь включить пакет на основе libtool в собственный проект, возможно, нестандартным способом. Вот моя цель:

  1. Сборка внешнего проекта: 

    ./configure --prefix=$HOME/blah --etcetera && make && make install

  2. Создайте свой собственный проект, который зависит от общих библиотек и исполняемых файлов внешнего проекта во время выполнения: 

    gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program

  3. Упакуйте все в один «локализованный» tarball ... то есть, пока у меня есть все в $HOME/blah на хосте сборки, я хочу иметь возможность извлекать tarball в любой произвольный каталог (на другом хосте) ) без необходимости futz с моим окружением. Цель состоит в том, чтобы позволить нескольким версиям моего проекта сосуществовать бок о бок без какого-либо неприятного «перекрестного опыления».

Я знаю, что могу использовать -rpath '$ORIGIN/../lib' для своего проекта, чтобы гарантировать, что нужные разделяемые библиотеки всегда загружаются во время выполнения. Тем не менее, похоже, что libtool настаивает на назначении собственной настройки -rpath на основе точного пути $HOME/blah/lib, который ломается, если мне удается распаковать все в другой каталог (скажем, например, $HOME/blah.2011-06-02).

Есть ли способ обойти это ограничение? Я вижу довольно продолжительное обсуждение rpath между участниками Debian и libtool на эту тему, но оно несколько старое и не дает окончательного ответа за пределами "мы не согласны".

1 Ответ

1 голос
/ 03 июня 2011

Среди опций, представленных здесь на Rpathissue в вики Debian, использование chrpath на этапе установки или какой-либо сценарий постобработки звучит как жизнеспособный вариант.(Он доступен на нескольких дистрибутивах через ваш любимый менеджер пакетов.)

Не требует исправления libtool, что является плюсом IMO.

Обратите внимание, что у него есть некоторые ограничения: можетСохраняйте новый rpath только в том случае, если он короче (или имеет ту же длину), что и исходный.

Другой (прагматичный) вариант - удалить rpath (это может сделать chrpath) и просто иметьскрипт-обёртка, который устанавливает LD_LIBRARY_PATH на то, что необходимо для вашего приложения.Это также может быть немного более переносимым (если вы работаете с другими средами пути совместно используемой библиотеки, которые есть в некоторых ОС).

...