Встановлення бібліотеки локально в домашній каталог, але програма не розпізнає її


10

Я встановлюю програму на сервер як некорінний користувач. Зокрема, це tmux 1.5, але це, на мою думку, має застосовуватися широко до всієї локально встановленої програми (я згадую назву програми у випадку, якщо ця проблема виявляється не моєю власною помилкою).

Програма вимагає від мене встановлення деяких залежних бібліотек (наприклад, libevent і ncurses). Отже, я встановив їх як локально, оскільки не маю доступу до кореня

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, але жодне з них не працювало. Будь-які ідеї та запропоновані пропозиції будуть дуже вдячні


Я припускаю, -R $DIR/libщо CFLAGSце будується tmux(а ні libevent). Це не допомогло мені - сталася якась остаточна помилка від gcc, яка сказала, що не може розпізнати -R(також я намагався без пробілу між -Rі $DIR). ./configure - відключити-спільно Це спрацювало, оновивши 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}

Нічого, дякую за швидку відповідь. Я вирішив проблему, використовуючи LD_LIBRARY_PATH, оскільки я міг просто застосувати це виправлення до будь-яких майбутніх бібліотечних установок і завжди використовувати $ HOME / локальний каталог. Вдячний за допомогу!
scicalculator



2

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

Я вважаю, що більш чистим підходом є використання так званого "rpath" - шляху пошуку бібліотеки, вбудованого у двійковий файл. -rpathПеремикач по крайней мере GNU линкер ldвказує шлях.

Потім командний рядок build виглядатиме так:

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?

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.