Scroll to navigation

ld.so(8) System Manager's Manual ld.so(8)

NAZWA

ld.so, ld-linux.so - dynamiczny konsolidator/ładowacz

SKŁADNIA

Konsolidator dynamiczny może być uruchomiony albo pośrednio przez uruchomienie jakiegokolwiek skonsolidowanego dynamicznie programu lub obiektu dzielonego (w tym przypadku żadna opcja wiersza poleceń nie będzie przekazana do konsolidatora dynamicznego i w przypadku ELF-a uruchomiony zostanie konsolidator dynamiczny przechowywany w sekcji .interp programu), albo bezpośrednio przez uruchomienie:

/lib/ld-linux.so.* [OPCJE] [PROGRAM [ARGUMENTY]]

OPIS

Programy ld.so i ld-linux.so* wyszukują i uruchamiają obiekty dzielone (biblioteki dzielone) wymagane przez program, przygotowują program do uruchomienia, a w końcu go uruchamiają.

Linuksowe pliki binarne wymagają konsolidacji dynamicznej (czyli konsolidacji podczas uruchamiania), chyba że podczas kompilacji programowi ld(1) przekazano opcję -static.

Program ld.so obsługuje pliki binarne w używanym dawno temu formacie binarnym a.out; Program ld-linux.so* (/lib/ld-linux.so.1 do libc5, /lib/ld-linux.so.2 do glibc2) obsługuje pliki binarne w nowszym formacie ELF. Oba programy zachowują się tak samo i używają tych samych plików pomocniczych i programów: ldd(1), ldconfig(8) oraz /etc/ld.so.conf.

Podczas rozwiązywania zależności obiektów dzielonych, konsolidator dynamiczny najpierw przegląda każdy łańcuch znaków zależności w poszukiwaniu znaku ukośnika (może wystąpić, jeśli podczas linkowania obiektu dzielonego podano nazwę ścieżki zawierającą ukośniki). Jeśli taki znak zostanie znaleziony, to łańcuch znaków zależności jest interpretowany jako nazwa (względnej lub bezwzględnej) ścieżki i obiekt dzielony jest ładowany, używając tej nazwy ścieżki.

Jeśli zależność od obiektu dzielonego nie zawiera znaku ukośnika, to potrzebne biblioteki dzielone są szukane w następującej kolejności:

(1)
Używa katalogów podanych w sekcji atrybutów dynamicznych DT_RPATH pliku binarnego, jeśli jest obecna i nie istnieje atrybut DT_RUNPATH.
(2)
Przy użyciu zmiennej środowiskowej LD_LIBRARY_PATH, chyba że plik wykonywalny jest uruchomiony w trybie bezpiecznego wykonania; (zob. niżej), gdy zmienna ta jest ignorowana.
(3)
Przy użyciu katalogów podanych w DT_RUNPATH w sekcji atrybutów dynamicznych pliku binarnego, jeśli występuje. Takie katalogi są przeszukiwane tylko w celu znalezienia obiektów wymaganych przez wpisy DT_NEEDED (bezpośrednie zależności) i nie stosuje się to do potomnych tych obiektów, które muszą posiadać swoje wpisy DT_RUNPATH. Różni się to od DT_RPATH, która stosuje się do przeszukiwań wszystkich potomków w drzewie zależności.
(4)
Z pliku bufora /etc/ld.so.cache, zawierającego skompilowaną listę obiektów dzielonych, poprzednio znalezionych w ścieżce obiektów dzielonych. Jeśli jednakże program binarny został skonsolidowany z opcją linkera -z nodefaultlib, to pomijane są obiekty dzielone z domyślnych ścieżek obiektów dzielonych. Preferowane są obiekty dzielone zainstalowane w katalogach zgodnych z właściwościami sprzętu (patrz niżej).
(5)
W domyślnej ścieżce /lib a potem w /usr/lib (na niektórych architekturach 64-bitowych domyślną ścieżką 64-bitowych obiektów dzielonych jest /lib64, a potem /usr/lib64). Ten krok jest pomijany, jeśli program binarny został skonsolidowany z opcją -z nodefaultlib konsolidatora.

Tokeny łańcuchów dynamicznych

W kilku miejscach konsolidator dynamiczny interpretuje tokeny łańcuchów dynamicznych:

•
W zmiennych środowiskowych LD_LIBRARY_PATH, LD_PRELOAD i LD_AUDIT,
•
wewnątrz wartości znaczników sekcji dynamicznej: DT_NEEDED, DT_RPATH, DT_RUNPATH, DT_AUDIT i DT_DEPAUDIT plików wykonywalnych ELF,
•
w argumentach do opcji wiersza poleceń: --audit, --library-path i --preload ld.so (zob. niżej) oraz
•
w argumentach z nazwą pliku do funkcji dlopen(3) i dlmopen(3).

Podstawiane tokeny to:

$ORIGIN (lub równoważnie ${ORIGIN})
Rozwija się do katalogu zawierającego program lub obiekt dzielony. Tak więc aplikacja znajdująca się w jakimśkatalogu/app może zostać skompilowana z

gcc -Wl,-rpath,'$ORIGIN/../lib'

tak żeby przypisane jej obiekty dzielone mogły być umieszczone w jakimśkatalogu/lib, niezależnie od tego, gdzie jakiśkatalog jest umieszczony w hierarchii katalogów. Umożliwia to tworzenie aplikacji, które nie muszą być instalowane w specjalnych katalogach, ale mogą po prostu być rozpakowane w dowolnym katalogu i wciąż będą mogły znaleźć swoje obiekty dzielone.
$LIB (lub równoważnie ${LIB})
Rozwija się do lib lub lib64 w zależności od architektury (np. na x86-64 rozwija się lib64, a na x86-32 rozwija się do lib).
$PLATFORM (lub równoważnie ${PLATFORM})
Rozwija się do łańcucha znaków odpowiadającego typowi procesora systemu (np. „x86_64”). Na niektórych architekturach jądro Linux nie przekazuje konsolidatorowi dynamicznemu oznaczenia platformy. Wartość tego łańcucha znaków jest pobierana z wartości AT_PLATFORM pomocniczego wektora (patrz getauxval(3)).

Proszę zauważyć, że tokeny łańcuchów dynamicznych przy ustawianiu z powłoki muszą być prawidłowo zacytowane, aby ochronić je przed interpretację przez powłokę jako zmienne środowiskowe lub powłoki.

OPCJE

Ustawia argv[0] na wartość łańcucha przed uruchomieniem programu.
Używa obiektów wymienionych na liście jako audytorów. Obiekty na liście rozdziela się przecinkiem.
Szuka wbudowanych podkatalogów tylko, jeśli występują na liście.
Szuka podkatalogów glibc-hwcaps z listy.
Nie używa /etc/ld.so.cache.
Używa ścieżki zamiast ustawienia zmiennej środowiskowej LD_LIBRARY_PATH (zob. niżej). Nazwy ORIGIN, LIB i PLATFORM są interpretowane w taki sam sposób, jak w przypadku zmiennej środowiskowej LD_LIBRARY_PATH.
Ignoruje informacje RPATH i RUNPATH w nazwach obiektów w liście. Opcja jest ignorowana podczas działania w trybie bezpiecznego wykonania (zob. niżej). Obiekty w liście rozdziela się dwukropkami lub spacjami.
Wyświetla wszystkie zależności wraz ze sposobem ich rozwiązania.
Wypisuje w formacie odczytywalnym maszynowo systemowe informacje diagnostyczne, takie jak pewne wewnętrzne zmienne ładowacza, wektor dodatkowy (zob. getauxval(3)) oraz zmienne środowiskowe. Na niektórych architekturach, polecenie może wypisać dodatkowe informacje (takie jak cechy procesora, stosowane przy niebezpośrednim wyborze funkcji GNU na x86).
Wypisuje nazwy wszystkich wartości dostosowywalnych, wraz z minimalnymi i maksymalnymi dozwolonymi wartościami.
Dokonuje wstępnego załadowania obiektów wymienionych w liście. Obiekty na liście rozdziela się dwukropkami lub spacjami. Obiekty są ładowane wstępnie zgodnie z opisem przy zmiennej środowiskowej LD_PRELOAD, poniżej.
W odróżnieniu od LD_PRELOAD, opcja --preload umożliwia dokonanie wstępnego załadowania dla pojedynczego pliku wykonywalnego, bez wpływania na załadowanie wstępne dokonywane we wszelkich procesach potomnych, które wykonują nowy program.
Sprawdza, że program jest konsolidowany dynamicznie i że ten konsolidator dynamiczny może go obsłużyć.

ŚRODOWISKO

Różne zmienne środowiska wpływają na działanie dynamicznego konsolidatora

Tryb bezpiecznego wykonania

Ze względów bezpieczeństwa, jeśli dynamiczny konsolidator określi, że plik binarny powinien być uruchomiony w trybie bezpiecznego wykonania, działanie niektórych zmiennych środowiskowych jest anulowane lub modyfikowane; co więcej te zmienne środowiskowe są wycinane ze środowiska, dzięki czemu program nawet nie widzi, że je zdefiniowano. Niektóre z tych zmiennych mają wpływ na działanie samego konsolidatora dynamicznego, jak to opisano poniżej. Inne zmienne środowiskowe traktowane w ten sposób obejmują: GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN, LD_AUDIT, LD_DEBUG, LD_DEBUG_OUTPUT, LD_DYNAMIC_WEAK, LD_HWCAP_MASK, LD_LIBRARY_PATH, LD_ORIGIN_PATH, LD_PRELOAD, LD_PROFILE, LD_SHOW_AUXV, LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS, TMPDIR i TZDIR.

Plik binarny jest wykonywany w trybie bezpiecznego wykonania, jeśli wpis AT_SECURE w dodatkowym wektorze (zob. getauxval(3)) ma niezerową wartość. Wpis ten może mieć niezerową wartość z różnych powodów, m.in.:

•
Rzeczywisty i efektywny identyfikator użytkownika procesu różnią się lub rzeczywisty i efektywny identyfikator grupy różnią się. Zwykle ma to miejsce jako rezultat wykonywania programu z set-user-ID lub set-group-ID.
•
Proces użytkownika z identyfikatorem niebędącym ID roota wykonał plik binarny, który nadał przywileje procesowi.
•
Niezerowa wartość mogła być ustawiona przez linuksowy moduł bezpieczeństwa - Linux Security Module.

Zmienne środowiskowe

Wśród ważniejszych zmiennych środowiskowych są następujące:

Każdy obiekt dzielony może informować konsolidator dynamiczny o wymaganej minimalnej wersji ABI jądra (To wymaganie jest zakodowane w sekcji „note” ELF-a; sekcja ta jest widoczna w readelf -n jako sekcja oznaczona NT_GNU_ABI_TAG). Podczas działania konsolidator dynamiczny określa wersję ABI uruchomionego jądra i odrzuca obiekty dzielone, które wymagają minimalnej wersji ABI większej niż wersja ABI uruchomionego jądra.
Za pomocą LD_ASSUME_KERNEL można spowodować, że konsolidator dynamiczny założy, iż jest uruchomiony na systemie z inną wersją ABI jądra. Na przykład następujący wiersz poleceń powoduje, że konsolidator dynamiczny podczas ładowania obiektów dzielonych wymaganych przez mójprog zakłada, że działa w systemie Linux 2.2.5

$ LD_ASSUME_KERNEL=2.2.5 ./mójprog

W systemach, które dostarczają wielu wersji obiektu dzielonego (w różnych katalogach w ścieżce wyszukiwania) o różnych minimalnych wymaganiach wersji ABI jądra, LD_ASSUME_KERNEL można użyć do wybrania tej wersji obiektu, która zostanie użyta (w zależności od porządku przeszukiwania katalogów).
Historycznie najczęstszym użyciem LD_ASSUME_KERNEL było ręczne wybieranie starszej implementacji POSIX-owych wątków LinuxThreads w systemach, które miały zainstalowane zarówno LinuxThreads, jak i NPTL (który był domyślną wersją na takich systemach); patrz pthreads(7).
Gdy zmienna ta jest obecna, sprawia, że dynamiczny konsolidator rozwiąże wszystkie symbole podczas startu programu, zamiast odkładać to, do wystąpienia pierwszego odniesienia. Jest to użyteczne podczas używania debuggera.
Lista katalogów, w których szukać bibliotek ELF podczas wykonywania. Składniki listy mogą być oddzielone dwukropkiem lub średnikiem, przy czym brak obsługi cytowania tych separatorów. Nazwa katalogu o zerowej długości wskazuje bieżący katalog roboczy.
Zmienna ignorowana w trybie bezpiecznego wykonania.
Wewnątrz ścieżek podanych w LD_LIBRARY_PATH, dynamiczny konsolidator rozwija tokeny $ORIGIN, $LIB i $PLATFORM (lub ich wersje otoczone nawiasami klamrowymi) zgodnie z powyższym opisem w rozdziale Tokeny łańcuchów dynamicznych. Z tego względu poniższy przykład spowodowałby poszukiwanie biblioteki w podkatalogach lib albo lib64, znajdujących się pod katalogiem zawierającym program do wykonania:

$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

(Proszę odnotować zastosowanie pojedynczych cudzysłowów, zapobiegających interpretacji $ORIGIN i $LIB jako zmiennych powłoki!)
Lista dodatkowych, podanych przez użytkownika, obiektów dzielonych ELF, które zostaną załadowane przed wszystkimi innymi. W ten sposób można wybiórczo przesłonić funkcje w innych obiektach dzielonych.
Pozycje na liście można rozdzielić spacjami lub dwukropkami, przy czym brak obsługi cytowania tych separatorów. Obiektów szuka się zgodnie z regułami w rozdziale OPIS. Obiektów szuka się i dodaje do mapy konsolidatora w kolejności od lewej do prawej, zgodnie z listą.
W trybie bezpiecznego wykonania, ścieżki wstępnego ładowania zawierające ukośniki są ignorowane. Co więcej, obiekty dzielone są ładowane wstępnie jedynie ze standardowych katalogów przeszukiwania i tylko, jeśli mają włączony bit set-user-ID (co nie jest standardem).
Spośród nazw wymienionych na liście LD_PRELOAD, dynamiczny konsolidator rozpoznaje tokeny $ORIGIN, $LIB i $PLATFORM (lub ich wersje otoczone nawiasami klamrowymi) zgodnie z opisem powyżej w rozdziale Tokeny łańcuchów dynamicznych (zob. też omówienie cytowania przy opisie LD_LIBRARY_PATH).
Istnieją różne metody na podanie bibliotek do załadowania wstępnego; są one obsługiwane w następującej kolejności:
(1)
Zmienna środowiskowa LD_PRELOAD.
(2)
Opcja wiersza poleceń --preload przy bezpośrednim przywoływaniu konsolidatora dynamicznego.
(3)
Plik /etc/ld.so.preload (opisany niżej).
Gdy zmienna ta jest ustawiona (na dowolną wartość) powoduje, że program wypisze swoje dynamiczne zależności, tak jakby był uruchomiany przez ldd(1), a nie normalnie.

Jest także wiele bardziej lub mniej mętnych zmiennych, wiele przestarzałych lub przeznaczonych do użytku wewnętrznego.

Lista określonych przez użytkownika dzielonych obiektów ELF do załadowania przed wszystkimi innymi obiektami w oddzielnej przestrzeni nazw konsolidatora (to jest w przestrzeni nazw, która nie wpływa na przyporządkowania symboli, które odbywa się w procesie). Obiektów tych można użyć do audytu operacji konsolidatora dynamicznego. Elementy na liście rozdziela się dwukropkiem, przy czym brak obsługi cytowania separatora.
LD_AUDIT jest ignorowana w trybie bezpiecznego wykonania.
Konsolidator dynamiczny powiadomi obiekty dzielone audytu w tak zwanych punktach sprawdzeń audytu — na przykład ładowanie nowego dzielonego obiektu, rozwiązanie symbolu lub wywołanie symbolu z innego obiektu dzielonego — przez wywołanie odpowiedniej funkcji obiektu dzielonego. Szczegóły można znaleźć w rtld-audit(7). Interfejs audytu jest w dużej mierze zgodny z tym udostępnianym przez Solarisa, opisanym w jego Przewodniku po konsolidatorze i bibliotekach w rozdziale Interfejs audytu konsolidatora.
Spośród nazw wymienionych na liście LD_AUDIT, dynamiczny konsolidator rozpoznaje tokeny $ORIGIN, $LIB i $PLATFORM (lub ich wersje otoczone nawiasami klamrowymi) zgodnie z opisem powyżej w Tokeny łańcuchów dynamicznych (zob. też omówienie cytowania przy opisie LD_LIBRARY_PATH).
Od glibc 2.13, w trybie bezpiecznego wykonania, nazwy w liście audytu zawierające ukośniki są ignorowane, a ładowane są jedynie obiekty dzielone w standardowych katalogach przeszukiwania, które mają ustawiony bit trybu set-user-ID.
Jeśli ta zmienna środowiskowa jest ustawiona na niepusty łańcuch, to nie zachodzi aktualizacja GOT (global offset table) ani PLT (procedure linkage table) po rozwinięciu symbolu funkcji. Łącząc stosowanie tej zmiennej z LD_DEBUG (z kategoriami bindings i symbols), można sprawdzić wszystkie przyporządkowania funkcji w czasie uruchomienia.
Wypisuje szczegółowe informacje debugowania o działaniu konsolidatora dynamicznego. Zawartość zmiennej obejmuje jedną lub więcej z poniższych kategorii, rozdzielonych dwukropkami, przecinkami albo (jeśli wartość ujęta w cytat) spacjami:
Podanie help w wartości zmiennej nie uruchamia podanego programu, natomiast wyświetla komunikat z pomocą na temat kategorii, jakie można umieścić w tej zmiennej środowiskowej.
Wypisuje wszystkie informacje debugowania (z wyjątkiem statistics i unused; zob. niżej).
Wyświetla informacje o definicji, do której dowiązany jest każdy z symboli.
Wyświetla postęp dotyczący plików wejściowych.
Wyświetla ścieżki przeszukiwania bibliotek.
Wyświetla przetwarzanie relokacji.
Wyświetla informacje o zasięgu.
Wyświetla statystyki relokacji.
Wyświetla ścieżki przeszukiwania wobec poszczególnych symboli.
Określa nieużywane DSO (obiekty dzielone dynamicznie).
Wyświetla wersję zależności.
Od glibc 2.3.4, LD_DEBUG jest ignorowane w trybie bezpiecznego wykonania, chyba że istnieje plik /etc/suid-debug (jest zawartość nie ma znaczenia).
Domyślnie, wynik LD_DEBUG jest wypisywany na standardowe wyjście błędów. Jeśli zdefiniowano LD_DEBUG_OUTPUT, wynik ten jest zapisywany do ścieżki podanej w jej wartości, z przyrostkiem „.” (kropka), po której następuje identyfikator procesu dołączony do ścieżki.
LD_DEBUG_OUTPUT jest ignorowana w trybie bezpiecznego wykonania.
Domyślnie, przy przeszukiwaniu bibliotek dzielonych, aby rozwiązać odniesienie symbolu, dynamiczny konsolidator skorzysta z pierwszej odnalezionej definicji.
Starsze wersje glibc (przed glibc 2.2), zachowywały się inaczej: gdy konsolidator odnalazł symbol typowany słabo, zapamiętywał go i szukał dalej w pozostałych bibliotekach dzielonych. Jeśli następnie znalazł ten sam symbol typowany silnie, używał go w zamian (jeśli nie odnaleziono innego symbolu, dynamiczny konsolidator użyłby pierwotnie odnalezionego symbolu słabego).
Stare zachowanie glibc było niestandardowe (standardową praktyką jest, że rozróżnienie pomiędzy symbolami typowanymi słabo i silnie ma miejsce tylko przy konsolidacji statycznej). W glibc 2.2, dynamiczny konsolidator zmodyfikowano w sposób zapewniający obecne zachowanie (było to też zachowanie większości innych implementacji w tamtym czasie).
Definiując zmienną środowiskową LD_DYNAMIC_WEAK (z dowolną wartością) zapewnia się stare (niestandardowe) zachowanie glibc, gdzie symbol typowany słabo w jednej z bibliotek dzielonych może być przesłonięty przez symbol typowany silnie odnaleziony później w innej bibliotece dzielonej (proszę zauważyć, że nawet gdy ta zmienna jest ustawiona, symbol typowany silnie w bibliotece dzielonej nie przesłoni tego samego symbolu typowanego słabo w głównym programie).
Od glibc 2.3.4, LD_DYNAMIC_WEAK jest ignorowana w bezpiecznym trybie wykonania.
Maska możliwości sprzętowych. Od glibc 2.26, opcja może zostać zignorowana, jeśli glibc nie obsługuje wartości dostosowywalnych.
Ścieżka, w której znaleziono program binarny.
Od wersji 2.4 biblioteki glibc LD_ORIGIN_PATH jest ignorowana w trybie bezpiecznego wykonania.
Ustawione na 0 powoduje wyłączenie ochrony wskaźników. Jakakolwiek inna wartość włącza ochronę wskaźników, co jest także zachowaniem domyślnym. Ochrona wskaźników jest mechanizmem bezpieczeństwa, w którym niektóre wskaźniki do kodu przechowywanego w zapisywalnej pamięci programu (adresy powrotu zwrócone przez setjmp(3) lub wskaźniki do funkcji używane przez różne funkcje wewnętrzne biblioteki glibc) są w sposób pseudolosowy zmieniane, aby utrudnić atakującemu przejęcie tych wskaźników i przeprowadzenie ataków typu przepełnienie bufora lub stosu. Od glibc 2.23 LD_POINTER_GUARD nie można już użyć do wyłączenia ochrony wskaźników, która jest teraz zawsze aktywna.
Nazwa (pojedynczego) obiektu dzielonego przeznaczonego do profilowania, podana albo jako nazwa ścieżki, albo nazwa pliku so. Wyjście profilowania jest dopisywane do pliku o nazwie $LD_PROFILE_OUTPUT/$LD_PROFILE.profile.
Od glibc w wersji 2.2.5, LD_PROFILE używa innej domyślnej ścieżki w trybie bezpiecznego wykonania.
Katalog, w którym powinno być zapisane wyjście LD_PROFILE. Jeśli ta zmienna nie jest zdefiniowana lub jeśli wartość tej zmiennej jest pusta, to domyślnym katalogiem jest /var/tmp.
LD_PROFILE_OUTPUT jest ignorowane w trybie bezpiecznego wykonania; wówczas zawsze używany jest /var/profile.
Jeśli ta zmienna środowiskowa jest zdefiniowana (z dowolną wartością), wyświetla tablicę pomocniczą przekazaną przez jądro (zob. też getauxval(3)).
Od wersji 2.3.4 biblioteki glibc LD_SHOW_AUXV jest ignorowana w trybie bezpiecznego wykonania.
Jeśli ta zmienna środowiskowa jest zdefiniowana, śledzi prekonsolidację obiektu, którego nazwa jest przypisana do tej zmiennej środowiskowej (ldd(1) służy do pozyskania listy obiektów, które mogą być śledzone). Jeśli nazwa obiektu nie zostanie rozpoznana, to śledzona jest cała aktywność prekonsolidacji.
Domyślnie (czyli jeśli ta zmienna nie jest zdefiniowana) programy wykonywalne i prekonsolidowane obiekty dzielone będą uwzględniały adresy bazowe obiektów dzielonych, od których zależą, a (nieprekonsolidowane) programy wykonywalne niezależne od pozycji (position-independent executable, PIE) i inne obiekty dzielone nie będą ich uwzględniały. Jeśli LD_USE_LOAD_BIAS jest zdefiniowana z jakąś wartością, to zarówno programy wykonywalne, jak i PIE, będą uwzględniały adresy bazowe. Jeśli LD_USE_LOAD_BIAS jest zdefiniowana z wartością 1, to ani programy wykonywalne, ani PIE nie będą uwzględniały adresów bazowych.
Od glibc 2.3.3 zmienna ta jest ignorowana w trybie bezpiecznego wykonania.
Jeśli ustawione na niepusty łańcuch znaków i jeśli została ustawiona zmienna środowiskowa LD_TRACE_LOADED_OBJECTS, to wypisuje informacje o wersjonowaniu symboli programu.
Jeśli ustawione na niepusty łańcuch znaków, to włącza ostrzeganie o nierozwijalnych symbolach.
Zgodnie z przewodnikiem optymalizacji oprogramowania Intel Silvermont, dla aplikacji 64-bitowych wydajność przewidywania rozgałęzień może być zmniejszona, gdy cel gałęzi jest oddalony o ponad 4 GB. Jeśli ta zmienna środowiskowa jest ustawiona (na dowolną wartość), to konsolidator dynamiczny spróbuje najpierw przypisać flagi wykonywalności za pomocą flagi MAP_32BIT mmap(2), a jeśli się to nie powiedzie — bez tej flagi. Przy okazji: MAP_32BIT przypisze niższe 2 GB (nie 4 GB) przestrzeni adresowej.
Ponieważ MAP_32BIT redukuje zakres adresowy dostępny dla losowego rozmieszczania obszarów pamięci (ang. ASLR - address space layout randomization), w trybie bezpiecznego wykonania LD_PREFER_MAP_32BIT_EXEC jest zawsze wyłączona.

PLIKI

/lib/ld.so
Dynamiczny konsolidator/ładowacz a.out
/lib/ld-linux.so.{1,2}
Dynamiczny konsolidator/ładowacz ELF
/etc/ld.so.cache
Plik zawierający skompilowaną listę katalogów, w których należy szukać obiektów dzielonych oraz uporządkowaną listę kandydujących obiektów dzielonych oraz wszelkie wartości dostosowywalne, jakie mają być zastosowane. Zob. ldconfig(8).
/etc/ld.so.preload
Pliki zawierające listę rozdzielonych odstępami obiektów dzielonych ELF, do załadowania przed programem. Zob. omówienie LD_PRELOAD powyżej. Jeśli stosuje się LD_PRELOAD oraz /etc/ld.so.preload, to jako pierwsze ładowane wstępnie są biblioteki podane w LD_PRELOAD. /etc/ld.so.preload ma działanie systemowe, powodując, że podane biblioteki są ładowane wstępnie dla wszystkich programów wykonywanych w systemie (zwykle jest to niepożądane i stosowane jedynie w sytuacjach kryzysowych, np. jako tymczasowe obejście nieprawidłowej konfiguracji biblioteki).
obiekty dzielone

UWAGI

Przestarzałe możliwości sprzętowe (glibc w wersji od 2.5 do 2.37)

Niektóre obiekty dzielone są kompilowane z użyciem specyficznych dla danego sprzętu instrukcji, które nie muszą istnieć na każdym CPU. Takie obiekty powinny być instalowane w katalogach, których nazwy określają wymagane właściwości sprzętu, na przykład /usr/lib/sse2/. Konsolidator dynamiczny porównuje nazwy takich katalogów ze sprzętem maszyny i wybiera najbardziej odpowiednią wersję danego obiektu dzielonego. Katalogi właściwości sprzętu mogą tworzyć kaskady, dopuszczając kombinacje cech CPU. Lista nazw wspieranych właściwości sprzętowych zależy od CPU. Obecnie rozpoznawane są następujące nazwy:

ev4, ev5, ev56, ev6, ev67
loongson2e, loongson2f, octeon, octeon2
4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe, ucache, vsx
flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9-109, z10, zarch
acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm

Obsługa przestarzałych możliwości sprzętowych ma tę wadę, że każda nowo dodana funkcja wykładniczo zwiększa ścieżkę wyszukiwania, ponieważ wymaga dodania do każdej kombinacji dotychczasowych funkcji.

Na przykład na 32-bitowej architekturze x86, jeśli sprzęt obsługuje i686 oraz sse2, wynikową ścieżką wyszukiwania będzie i686/sse2:i686:sse2:. Dodanie nowej możliwości nowamożl ustawi ścieżkę wyszukiwania na nowamożl/i686/sse2:nowamożl/i686:nowamożl/sse2:nowamożl:i686/sse2:i686:sse2:.

Możliwości sprzętowe glibc (od wersji 2.33 glibc)

w którym dla każdej architektury procesora można zdefiniować określone poziomy, grupujące wybrane funkcje lub specjalne instrukcje. Każdy poziom architektury ma stały zestaw ścieżek, które są dodawane do listy wyszukiwania dynamicznego konsolidatora, w zależności od sprzętu na komputerze. Jako że nowe poziomy architektury nie są łączone z poprzednio istniejącymi, nowy schemat nie ma wady w postaci niekontrolowanego rozrostu listy wyszukiwania konsolidatora dynamicznego.

Na przykład na 64-bitowej architekturze x86, jeśli sprzęt obsługuje x86_64-v3 (np. Intel Haswell lub AMD Excavator), wynikową ścieżką wyszukiwania będzie glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. Obecnie obsługiwane są poniższe ścieżki, w kolejności ich priorytetu.

power10, power9
z16, z15, z14, z13
x86-64-v4, x86-64-v3, x86-64-v2

W wersji glibc 2.37 usunięto obsługę przestarzałych możliwości sprzętowych.

ZOBACZ TAKŻE

ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5), ld.so.conf(8), capabilities(7), rtld-audit(7), ldconfig(8), sln(8)

TŁUMACZENIE

Tłumaczenie niniejszej strony podręcznika: Przemek Borys <pborys@dione.ids.pl>, Grzegorz Goławski <grzegol@pld.org.pl>, Robert Luberda <robert@debian.org> i Michał Kułach <michal.kulach@gmail.com>

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-list@lists.sourceforge.net.

3 sierpnia 2026 r. Linux man-pages 6.20