Do czego używany jest ld_library_path?

Przed poznaniem ścieżki LD_library powinieneś mieć pojęcie zmiennych środowiskowych. Ale jeśli nie wiesz, nie martw się, wyjaśniam, co to jest. Zmienne, których wartość jest określana przez system operacyjny lub zdolność mikrousług, nazywane są zmiennymi środowiskowymi. Zmienna środowiska to dynamicznie wyznaczona wartość, która może wpłynąć na sposób zachowania uruchamiania procesów komputerowych. Proces jest wykonywany w elemencie środowiska procesu.

Najpierw opracowano zmienne środowiskowe dla Unix, ale teraz Windows i Linux mają również te zmienne. Po utworzeniu pewnego procesu dziedziczy kopię środowiska wykonawczego rodzica, z wyjątkiem wyraźnych zmian dokonanych przez rodzica, gdy dziecko jest tworzone domyślnie. Para nazwy/wartości stanowi zmienną środowiskową, a dowolna ich liczba może być wygenerowana i odwołana w dowolnym momencie. Powszechnie litery górnych przypadków są używane podczas nazywania zmiennych środowiskowych. Pomaga to odróżnić zmienne środowiskowe od innych typów nazw w kodzie programowania w ogóle.W systemie operacyjnym UNIX zmienne środowiskowe są wrażliwe na literę, ale nie na DOS, OS/2 lub Windows.

LD_Library jest również zmienną środowiskową systemu operacyjnego UNIX/Linux; W tym artykule szczegółowo omówimy tę zmienną środowiskową.

Zastosowanie zmiennej LD_LiBRARY_PATH

W systemie Unix/Linux Ld_library_path Aby poinformować Dynamic Link Loader, niewielki program, który rozpoczyna wszystkie Twoje aplikacje, aby ustalić, gdzie szukać dynamicznych bibliotek współdzielonych, z którymi aplikacja była powiązana. Dwukropek (:) oddziela listę katalogów, a lista ta jest sprawdzana nawet przed wbudowaną ścieżką/ścieżkami wyszukiwania i konwencjonalnymi lokalizacjami, takimi jak (/lib,/usr/lib…).

Niektóre inne zastosowania ld_library_path to:

• Porównywanie nowych wersji wspólnej biblioteki z aplikacją, która została wcześniej skompilowana.
• Na przykład przeniesienie wspólnych bibliotek w celu utrzymania poprzednich wersji przy życiu.
• Służy również do tworzenia samowystarczalnego systemu, przenoszonego środowiska dla większych aplikacji, aby były one niezależne od zmiany bibliotek systemowych.

Problem z ld_library_path

Jest to bardzo przydatne, dopóki nie spróbujesz go użyć do rozwiązania problemów. Ta linia wydaje się dziwna, ale to właśnie dzieje się, gdy próbujesz zastosować ją w środowisku użytkownika/systemu, scenariusz staje się coraz gorszy, a wszystkie zmienne środowiskowe zaczynają się od tego i rozbija się, ponieważ nie może obsługiwać wszystkich zadań!

Niektóre problemy związane z użyciem LD_LiBRARY_PATH to:

Bezpieczeństwo: LD_LIBRARY_PATH DIREGOROTY są najpierw sprawdzane, zanim ich faktyczna lokalizacja. Takie podejście może zostać wykorzystane przez złośliwą osobę do zmuszenia aplikacji do uruchomienia złośliwej wersji wspólnej biblioteki. Jednym z powodów, dla których wykonywacze SETUID/SETGID ignorują tę zmienną, jest z tego powodu.

Wydajność: Link Loader musi szukać we wszystkich dostarczonych katalogach, dopóki nie znajdzie udostępnianych bibliotek (połączone z aplikacją). W konsekwencji spowoduje otwarcie kilku wywołanych systemem i spowoduje awarię z enoentem „Brak takiego pliku ani katalogu”. Jeśli określona ścieżka ma wiele katalogów, zajmie to dużo czasu i możesz sprawdzić to od czasu uruchamiania aplikacji. W rezultacie spowoduje to spowolnienie całego systemu.

Niezgodność: Najbardziej rozpowszechnionym problemem spowodowanym użyciem ld_library_path jest niespójność. LD_LIBRARY_PATH zmusza program do załadowania współdzielonej biblioteki, z którą nie był powiązany, co jest z pewnością niezgodne z oryginalną wersją. Może to być wysoce widoczne, na przykład gdy aplikacja się zawiesza lub może spowodować nieprawidłowe wyniki, jeśli biblioteka odebrana nie pasuje do funkcjonalności oryginalnej wersji. Będzie to trudne do debugowania tego ostatniego, zwłaszcza.

Rozwiązanie

Najlepszym rozwiązaniem jest mniej go używasz, tym mniej kłopotów napotkasz. W rzeczywistości staraj się unikać użycia ld_library_path:

Jak uniknąć ld_library_path:

Podaj prawidłową lokalizację biblioteki udostępnionej: Podczas kompilacji aplikacji musisz podać dokładną lokalizację współdzielonych bibliotek i określić ścieżkę w opcji linkera „-Rpath”, aby poinformować linker, aby dołączyć je do ścieżki Runpath Exceutable lub możesz użyć zmiennej LD_RUN_PATH, aby określić wiele ścieżek

Narzędzie do rozwiązania problemu:Aby naprawić/zmienić ścieżkę runda binarnego wykonywalnego, dostępne są programy, takie jak CHRPath pod Linux. Problem w ten sposób polega na tym, że przestrzeń wykonywacza, która przenosi te informacje (i.mi. ciąg ścieżki) nie można rozszerzyć, i.mi. możesz tylko przepisać istniejącą ścieżkę.

Nie umieszczaj ld_library_path w profilu użytkownika: Umieszczając ld_library_path w profilu użytkownika, tworzysz problemy dla siebie, więc unikaj tego.

Nie umieszczaj ld_library_path w profilu systemu: Niektóre ISV zapewniają oprogramowanie, które automatycznie wstawiają globalne ustawienia ścieżki biblioteki LD do profili systemowych podczas instalacji, a nawet montują użytkownika do tego. Po prostu powiedz nie! Spróbuj poradzić sobie z problemem w inny sposób, na przykład, pisząc skrypt opakowania lub powiedz dostawcy, aby go naprawił.

LD_LIBRARY_PATH jest użyteczny, jeśli używany do trzech zastosowań, które są wymienione w części użytkowania, ale staraj się go użyć jak najmniej, aby chronić się przed kłopotami.

Wniosek

Ld_library_path jest zmienną środowiskową stosowaną w systemach Linux/Unix. Służy do informowania dynamicznych ładowarków, gdzie szukać współdzielonych bibliotek dla określonych aplikacji. Jest to przydatne, dopóki nie będziesz z tym nie zadzierać. Lepiej jest unikać korzystania z LD_Library_Path i użyć alternatyw. W tym artykule omówiono użycie zmiennej środowiskowej LD_LiBRARY_PATH. Po przeczytaniu tego artykułu poznasz zalety i wady zmiennej LD_Library_Path.