Prawidłowe użycie LD_LIBRARY_PATH lub ldconfig dla pakietu oprogramowania

Question

Jestem świadomy ogólnych podstaw korzystania z ldconfig i LD_LIBRARY_PATH, ale mam nadzieję na małą pomoc guru w mojej sytuacji.

Mam przenośny pakiet oprogramowania, który znajduje się we własnym katalogu i ma własne wersje wielu bibliotek.

Istnieje wiele plików binarnych i skryptów uruchamianych z tego katalogu.

Niektóre pliki binarne (apache, php, postgres) mogą również mieć oddzielne wersje zainstalowane w systemie.

Ponieważ mogą występować dwie wersje php, nie wystarczy utworzyć /etc/ld.so.conf.d/myapp.conf, jeśli system nie może określić, której wersji "myapp" należy użyć do pliku ldconfig.

Szukam najlepszych praktyk dotyczących konfiguracji takiego systemu. Osoba, która początkowo ustawiła pakiet oprogramowania, wyeksportowała numer LD_LIBRARY_PATH, aby wszystkie aplikacje w systemie z niego korzystały.

Próbuję odizolować tylko aplikacje w katalogu pakietów.

Niektóre parametry do pracy z:

/mypack - zawiera wszystko dla pakietu oprogramowania

/mypack/local/lib - zawiera wymaganych bibliotek, które mogą nie być kompatybilne z systemem

przykład biblioteka:

/mypack/local/lib/libz.so.1 => /mypack/local/lib/libz.so.1.2.3 
/lib/libz.so.1 => /lib/libz.so.1.2.3 

mimo że wersje są takie same, ten w/mypack może nie być kompatybilne z dystrybucji i złamie systemu, jeśli jest używany

przykład binarny: php istnieje zarówno w/mypack w domyślnym katalogu php z/mypack powinien wykorzystać bibliotekami z/mypack/local/lib i wersja dystrybucyjna powinna używać/lib

Kilka pytań o ścieżki biblioteki linuksowej: - Czy możliwe jest podanie /etc/ld.so.conf.d/php.conf tak, aby miało wpływ tylko na wersję php w/mypack ? - Czy ścieżka biblioteki może być określona na podstawie położenia pliku wykonywalnego? Oznacza to, że w czasie wykonywania, jeśli ścieżka do pliku wykonywalnego jest pod/mypack, czy może automatycznie korzystać z bibliotek? - A co z użytkownikiem? Niektóre/większość systemu działa na różnych kontach użytkowników. Gdybym był w stanie ustawić inną ścieżkę biblioteki na użytkownika, to by to rozwiązało.

Answer 1

na wypadek gdyby ktoś inny znajdzie to użyteczne, skończyło się w ten sposób przed budynkiem:

export LD_RUN_PATH='$ORIGIN/../lib' 

ten zawiera ścieżkę do bibliotek w samej binarnym, w stosunku do lokalizacji pliku binarnego. Jeśli zamierzasz użyć tego w skrypcie basha lub w plikach budowania, upewnij się, że sprawdziłeś swoje konkretne użycie za pomocą $ ORIGIN, ponieważ istnieją przypadki, w których musisz zrobić coś takiego, jak \ $$ ORIGIN, \ $$ ORIGIN lub $$ ORIGIN, aby różne narzędzia zaangażowane w kompilację otrzymywały znak dolara właściwie. Znalezienie tego przydatnego narzędzia pozwoliło mi zaktualizować około 50 pojedynczych skryptów, które działają jako partia do zbudowania naszego pakietu oprogramowania.

Answer 2

Problem polega na tym, że LD_LIBRARY_PATH poprzedza informacje dostarczane przez ldconfig. Jeśli wszystko, co chcesz zrobić, to mieć zestaw bibliotek zapasowych do instalacji na systemach, które nie mają już je wyodrębnić bieżący zestaw bibliotek z ldconfig i poprzedzić je do LD_LIBRARY_PATH

mytmp=/tmp/${USER}_junk$$ 
(for i in `/sbin/ldconfig -p | grep '=>' | awk '{ print $NF }'` ; do dirname $i ; done) | sort -r | uniq > ${mytmp} 
myld="" 
for j in `cat ${mytmp}` ; do myld=${j}:${myld} ; done 
rm -f ${mytmp} 
LD_LIBRARY_PATH=${myld}${LD_LIBRARY_PATH}:${SEP}/lib:${SEP}/lib/syslibs 
export LD_LIBRARY_PATH