Установка библиотеки локально в домашнем каталоге, но программа не распознает ее

10

Я устанавливаю программу на сервер как пользователь без полномочий root. В частности, это tmux 1.5, но, на мой взгляд, это должно распространяться на все локально установленные программы (я упоминаю название программы на случай, если эта проблема не станет моей собственной ошибкой).

Программа требует от меня установки некоторых зависимых библиотек (например, libevent и ncurses). Итак, я установил их оба локально, так как у меня нет доступа с правами root

cd $HOME/library/installation/folder
DIR=$HOME/local
./configure --prefix=$DIR 
#... make ... make install

Теперь, чтобы установить программу, мне также пришлось включить библиотечные пакеты:

cd $HOME/program/installation/folder
./configure --prefix=$DIR CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib"
#... make ... make install

Итак, это без проблем устанавливает программу в $ HOME / local / bin, но если я запускаю исполняемый файл: $ HOME / local / bin / tmux, я получаю следующую ошибку:

tmux: ошибка при загрузке общих библиотек: libevent-2.0.so.5: невозможно открыть общий объектный файл: нет такого файла или каталога

Мне может показаться, что программа не может найти нужные библиотеки, но файл libevent-2.0.so.5 действительно существует в $ HOME / local / lib, как указано в параметрах конфигурации. Мне интересно, как я могу заставить программу распознавать установленную библиотеку для запуска. Я пытался поместить символические ссылки в $ HOME / lib, $ HOME / bin и $ HOME / local / bin, но ни одна из них не сработала. Любые идеи и предложения будут с благодарностью

linux installation terminal libraries home-directory scicalculator
источник
Я предполагаю, -R $DIR/libчто CFLAGSэто во время строительства tmux(а не libevent). Это не помогло мне - была последняя ошибка от gcc, говорящая, что он не может распознать -R(также я пробовал без пробела между -Rи $DIR). ./configure --disable-shared Это сработало, обновление LD_LIBRARY_PATHтакже сработало. Я закончил тем, что сделал libeventснова с вышеупомянутым --disable-sharedвыбором.

Ответы:

20

Попробуйте перестроить libevent, используя

./configure --disable-shared

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

В качестве альтернативы, если вам нужен динамически связанный libevent, вы можете добавить содержащий каталог libevent-2.0.so.5 в переменную среды LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=${HOME}/local/lib/:${LD_LIBRARY_PATH}
drootang
источник
Вау, большое спасибо за быстрый ответ. Я решил использовать LD_LIBRARY_PATH, чтобы исправить проблему, поскольку я мог просто применить это исправление к любым будущим установкам библиотеки и всегда использовать каталог $ HOME / local. Ценю помощь!
scicalculator
2

Не повезло с другими, но это сработало для меня, отсюда :

sudo ln -s /usr/local/lib/libevent-2.0.so.5 /usr/lib64/libevent-2.0.so.5
beardc
источник
2

Я задал аналогичный вопрос , достаточно интересно, также о построении tmuxвсех вещей (хотя я все еще уверен, что это относится практически к любой ситуации, когда GNU configureи makeиспользуются вместе.

Я считаю, что более чистый подход заключается в использовании так называемого «rpath» - пути поиска библиотеки, встроенного в двоичный файл. -rpathПереключатель по крайней мере GNU линкер ldуказывает путь.

Командная строка сборки будет выглядеть следующим образом:

PKG_CONFIG_PATH=/path/to/libevent/lib/pkg-config LDFLAGS=-Wl,-rpath,/path/to/libevent/lib ./configure ...

Не очень первостепенные здесь, но PKG_CONFIG_PATHвыше , это просто рекомендуемый способ сделать то , что люди , в противном случае добиться вручную отправок -L/path/to/libevent/lib -I/path/to/libevent/includeв ./configureсценарий. Когда вы строите libevent, он устанавливает свои собственные файлы конфигурации для pkg-config(который используется ./configure). Вы должны использовать это, потому что только libevent определенно знает, какие ключи должны быть использованы при построении против него.

Во всяком случае, в некоторых ситуациях -rpathэто более чистый подход к решению проблемы.

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

Странно то, что tmux«собственные сценарии сборки не выводят этот путь из пути поиска библиотеки во время сборки. Может быть, они не нуждаются и не должны, я не знаю. Случайно ли это с нами, кто строит tmux?

атп
источник