Lokalna instalacja biblioteki w katalogu domowym, ale program jej nie rozpoznaje

10

Instaluję program na serwerze jako użytkownik inny niż root. W szczególności jest to Tmux 1.5, ale moim zdaniem powinno to dotyczyć ogólnie wszystkich programów zainstalowanych lokalnie (wymieniam nazwę programu, na wypadek gdyby ten problem nie był moim błędem).

Program wymaga zainstalowania niektórych bibliotek zależnych (np. Libevent i ncurses). Więc zainstalowałem je oba lokalnie, ponieważ nie mam dostępu do roota

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

Teraz, aby zainstalować program, musiałem również dołączyć pakiety bibliotek:

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

Ok, więc to instaluje program bez problemów do $ HOME / local / bin, ale jeśli uruchomię plik wykonywalny: $ HOME / local / bin / tmux, pojawia się następujący błąd:

tmux: błąd podczas ładowania bibliotek współdzielonych: libevent-2.0.so.5: nie można otworzyć pliku obiektu współdzielonego: brak takiego pliku lub katalogu

Wydaje mi się, że program nie może znaleźć pożądanych bibliotek, ale plik libevent-2.0.so.5 rzeczywiście istnieje w $ HOME / local / lib, jak określono w opcjach konfiguracji. Zastanawiam się, jak mogę uruchomić program, aby rozpoznał zainstalowaną bibliotekę. Próbowałem umieścić dowiązania symboliczne w $ HOME / lib, $ HOME / bin i $ HOME / local / bin, ale żadne z nich nie zadziałało. Wszelkie pomysły i sugestie będą mile widziane

— Scicalculator
źródło

Zakładam, -R $DIR/libże CFLAGSjest w trakcie budowy tmux(i nie libevent). To mi nie pomogło - był jakiś końcowy błąd z gcc, który powiedział, że nie może rozpoznać -R(próbowałem również bez spacji między -Ri $DIR). ./configure --disable-shared To działało, aktualizacja LD_LIBRARY_PATHrównież działało. Skończyło się na zrobieniu libeventponownie z powyższą --disable-sharedopcją.

20

Spróbuj ponownie zbudować libevent przy użyciu

./configure --disable-shared

Podejrzewam, że to rozwiąże twój problem, ponieważ biblioteka zostanie połączona podczas tworzenia pliku binarnego i nie trzeba jej przeszukiwać w czasie wykonywania.

Alternatywnie, jeśli potrzebujesz dynamicznie połączonego libevent, możesz dodać katalog zawierający libevent-2.0.so.5 do zmiennej środowiskowej LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=${HOME}/local/lib/:${LD_LIBRARY_PATH}

— drootang
źródło

Wow, wielkie dzięki za szybką odpowiedź. Skończyło się na użyciu LD_LIBRARY_PATH, aby naprawić problem, ponieważ mogłem po prostu zastosować tę poprawkę do każdej przyszłej instalacji biblioteki i zawsze używać katalogu $ HOME / local. Doceń pomoc!

— Scicalculator

7

Możesz także ustawić RPATH, która koduje łatkę przeszukiwania biblioteki w samym pliku binarnym .

Po prostu dodaj -R $DIR/libdo CFLAGS.

— Łatki
źródło

2

Nie mam szczęścia z innymi, ale to zadziałało dla mnie stąd :

sudo ln -s /usr/local/lib/libevent-2.0.so.5 /usr/lib64/libevent-2.0.so.5

— broda
źródło

2

Zadałem podobne pytanie , co ciekawe, także o budowaniu tmuxwszystkich rzeczy (chociaż wciąż jestem pewien, że dotyczy to niemal każdej sytuacji, w której GNU configurei makesą używane razem.

Wierzę, że czystszym podejściem jest wykorzystanie tak zwanej „rpath” - ścieżki wyszukiwania biblioteki osadzonej w pliku binarnym. -rpathPrzełącznik przynajmniej GNU łącznik ldokreśla ścieżkę.

Wiersz polecenia kompilacji wyglądałby wtedy następująco:

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

Nie tak naprawdę tutaj najważniejsze, ale PKG_CONFIG_PATHpowyżej jest po prostu zalecanym sposobem na to, co ludzie robią ręcznie, wysyłając -L/path/to/libevent/lib -I/path/to/libevent/includena ./configureskrypt. Podczas kompilacji libeventinstaluje własne pliki konfiguracyjne dla pkg-config(z których korzysta ./configure). Powinieneś go użyć, ponieważ tylko na libevent pewno wie, jakich przełączników należy użyć podczas budowania przeciwko niemu.

W każdym razie w niektórych sytuacjach -rpathjest to czystsze podejście do rozwiązania problemu.

LD_LIBRARY_PATHoparte na rozwiązaniach pozwalają jednak żonglować biblioteką używaną przez wbudowany plik binarny w czasie wykonywania, co jest czasem pożądane. Ale jeśli chcesz po prostu zbudować w oparciu o określoną bibliotekę, którą umieściłeś gdzieś w specjalnym miejscu w folderze domowym, myślę -rpath, że oparte na rozwiązaniach rozwiązania należy traktować jako odpowiedź kanoniczną.

Dziwne jest to, dlaczego tmuxwłasne skrypty budowania nie wywodzą tej ścieżki ze ścieżki przeszukiwania biblioteki podczas budowania. Może nie potrzebują i nie powinni, nie wiem. Czy to przypadek, że przytrafiło się nam, którzy budujemy tmux?

— amn
źródło