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

NUME
       ld.so, ld-linux.so - editor de legaturi/incarcator dinamic

SINOPSIS
       Editorul de legaturi dinamice poate fi rulat fie indirect, prin rularea
       unui program legat dinamic sau a unui obiect partajat (caz in care nu
       pot fi transmise op<?>iuni din linia de comanda catre editorul de
       legaturi dinamice <?>i, in cazul ELF, este executat editorul de
       legaturi dinamice care este stocat in sec<?>iunea .interp a
       programului), fie direct, prin rularea:

       /lib/ld-linux.so.* [OP<?>IUNI] [PROGRAM [ARGUMENTE]]

DESCRIERE
       Programele ld.so <?>i ld-linux.so* gasesc <?>i incarca obiectele
       partajate (biblioteci partajate) necesare unui program, pregatesc
       programul pentru execu<?>ie <?>i apoi il executa.

       Binarele Linux necesita legare dinamica (legare in timpul execu<?>iei),
       cu excep<?>ia cazului in care op<?>iunea -static a fost data la ld(1)
       in timpul compilarii.

       Programul ld.so gestioneaza binarele a.out, un format binar utilizat cu
       mult timp in urma. Programul ld-linux.so* (/lib/ld-linux.so.1 pentru
       libc5, /lib/ld-linux.so.2 pentru glibc2) gestioneaza binarii care sunt
       in formatul ELF mai modern. Ambele programe au acela<?>i comportament
       <?>i utilizeaza acelea<?>i fi<?>iere <?>i programe de suport (ldd(1),
       ldconfig(8) <?>i /etc/ld.so.conf).

       La rezolvarea dependen<?>elor obiectelor partajate, editorul de
       legaturi dinamice inspecteaza mai intai fiecare <?>ir de dependen<?>e
       pentru a vedea daca acesta con<?>ine o bara oblica (acest lucru se
       poate intampla daca un nume de ruta al unui obiect partajat care
       con<?>ine bara oblica a fost specificat la momentul realizarii
       legaturii). Daca se gase<?>te o bara oblica, atunci <?>irul de
       dependen<?>a este interpretat ca un nume de ruta (relativ sau absolut),
       iar obiectul partajat este incarcat folosind acel nume de ruta.

       Daca o dependen<?>a de obiect partajat nu con<?>ine o bara oblica,
       atunci este cautata in urmatoarea ordine:

       (1)  Utilizand directoarele specificate in atributul DT_RPATH al
            sec<?>iunii dinamice a binarului, daca este prezent <?>i atributul
            DT_RUNPATH nu exista.

       (2)  Utilizand variabila de mediu LD_LIBRARY_PATH, cu excep<?>ia
            cazului in care executabilul este rulat in modul de
            execu<?>ie-securizata (a se vedea mai jos), caz in care aceasta
            variabila este ignorata.

       (3)  Utilizand directoarele specificate in atributul DT_RUNPATH al
            sec<?>iunii dinamice a binarului, daca este prezent. Aceste
            directoare sunt cautate numai pentru a gasi obiectele solicitate
            de intrarile DT_NEEDED (dependen<?>e directe) <?>i nu se aplica
            copiilor acelor obiecte, care trebuie sa aiba propriile lor
            intrari DT_RUNPATH.  Acest lucru este diferit de DT_RPATH, care se
            aplica cautarilor pentru to<?>i copiii din arborele de
            dependen<?>e.

       (4)  Din fi<?>ierul cache /etc/ld.so.cache, care con<?>ine o lista
            compilata de obiecte partajate candidate gasite anterior in ruta
            bibliotecii augmentate. Daca, totu<?>i, binarul a fost legat cu
            op<?>iunea editorului de legaturi -z nodefaultlib, obiectele
            partajate din rutele implicite sunt ignorate. Obiectele partajate
            instalate in directoarele de capacita<?>i hardware (a se vedea mai
            jos) sunt preferate altor obiecte partajate.

       (5)  In ruta implicita /lib, <?>i apoi /usr/lib; (pe unele arhitecturi
            pe 64 de bi<?>i, rutele implicite pentru obiectele partajate pe 64
            de bi<?>i sunt /lib64, <?>i apoi /usr/lib64). Daca binarul a fost
            legat cu op<?>iunea editorului de legaturi -z nodefaultlib, acest
            pas este sarit.

   Simboluri dinamice de <?>ir
       In numeroase locuri, editorul de legaturi dinamice extinde simbolurile
       <?>irurilor dinamice:

       o  In variabilele de mediu LD_LIBRARY_PATH, LD_PRELOAD <?>i LD_AUDIT,

       o  in interiorul valorilor etichetelor de sec<?>iune dinamica
          DT_NEEDED, DT_RPATH, DT_RUNPATH, DT_AUDIT <?>i DT_DEPAUDIT ale
          binarelor ELF,

       o  in argumentele op<?>iunilor de linie de comanda ld.so --audit,
          --library-path <?>i --preload (a se vedea mai jos), <?>i

       o  in argumentele de nume de fi<?>ier pentru func<?>iile dlopen(3) <?>i
          dlmopen(3).

       Simbolurile substituite sunt urmatoarele:

       $ORIGIN (sau echivalent ${ORIGIN})
              Aceasta se extinde la directorul care con<?>ine programul sau
              obiectul partajat. Astfel, o aplica<?>ie localizata in
              vreun-dir/aplica<?>ie ar putea fi compilata cu

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

              astfel incat sa gaseasca un obiect partajat asociat in
              vreun-dir/biblioteca indiferent unde se afla vreun-dir in
              ierarhia directoarelor. Acest lucru faciliteaza crearea de
              aplica<?>ii ,,la cheie" care nu trebuie sa fie instalate in
              directoare speciale, ci pot fi despachetate in orice director
              <?>i i<?>i pot gasi in continuare propriile obiecte partajate.

       $LIB (sau echivalent ${LIB})
              Aceasta se extinde la lib sau lib64 in func<?>ie de arhitectura
              (de exemplu, pe x86-64, se extinde la lib64 <?>i pe x86-32, se
              extinde la lib).

       $PLATFORM (sau echivalent ${PLATFORM})
              Acesta se extinde la un <?>ir corespunzator tipului de procesor
              al sistemului gazda (de exemplu, ,,x86_64"). Pe unele
              arhitecturi, nucleul Linux nu furnizeaza un <?>ir de platforma
              pentru editorul de legaturi dinamice. Valoarea acestui <?>ir
              este preluata din valoarea AT_PLATFORM din vectorul auxiliar
              (consulta<?>i getauxval(3)).

       Re<?>ine<?>i ca simbolurile de <?>ir dinamice trebuie sa fie citate
       corespunzator atunci cand sunt definite dintr-un shell, pentru a
       preveni extinderea lor ca variabile de shell sau de mediu.

OP<?>IUNI
       --argv0 <?>ir (incepand cu glibc 2.33)
              Stabile<?>te argv[0] la valoarea <?>ir inainte de a rula
              programul.

       --audit lista
              Utilizeaza obiectele numite in lista ca auditori. Obiectele din
              lista sunt delimitate prin doua puncte.

       --glibc-hwcaps-mask lista
              Cauta subdirectoare incorporate numai daca sunt in lista.

       --glibc-hwcaps-prepend lista
              Cauta subdirectoarele glibc-hwcaps din lista.

       --inhibit-cache
              Nu utilizeaza /etc/ld.so.cache.

       --library-path ruta
              Utilizeaza ruta in locul valorii variabilei de mediu
              LD_LIBRARY_PATH (a se vedea mai jos). Numele ORIGIN, LIB <?>i
              PLATFORM sunt interpretate ca pentru variabila de mediu
              LD_LIBRARY_PATH.

       --inhibit-rpath lista
              Ignora informa<?>iile RPATH <?>i RUNPATH in numele obiectelor
              din lista. Aceasta op<?>iune este ignorata la rularea in modul
              de execu<?>ie securizata (a se vedea mai jos). Obiectele din
              lista sunt delimitate prin doua puncte (,,:") sau spa<?>ii.

       --list Listeaza toate dependen<?>ele <?>i modul in care acestea sunt
              rezolvate.

       --list-diagnostics (incepand cu glibc 2.33)
              Imprima informa<?>ii de diagnosticare a sistemului intr-un
              format care poate fi citit de ma<?>ina, cum ar fi unele
              variabile interne ale incarcatorului, vectorul auxiliar (vezi
              getauxval(3)) <?>i variabilele de mediu. Pe unele arhitecturi,
              comanda poate afi<?>a informa<?>ii suplimentare (cum ar fi
              caracteristicile cpu utilizate in selectarea indirecta a
              func<?>iilor GNU pe x86). --list-tunables (de la glibc 2.33)
              Imprima numele <?>i valorile tuturor variabilelor de ajustare,
              impreuna cu valorile minime <?>i maxime permise.

       --preload list (incepand cu glibc 2.30)
              Preincarca obiectele specificate in lista.  Obiectele din lista
              sunt delimitate prin doua puncte (,,:") sau spa<?>ii. Obiectele
              sunt preincarcate dupa cum se explica in descrierea variabilei
              de mediu LD_PRELOAD de mai jos.

              Spre deosebire de LD_PRELOAD, op<?>iunea --preload ofera o
              modalitate de a efectua preincarcarea pentru un singur
              executabil fara a afecta preincarcarea efectuata in orice proces
              copil care executa un program nou.

       --verify
              Verifica<?>i daca programul este legat dinamic <?>i daca acest
              editor de legaturi dinamice il poate gestiona.

MEDIU
       Diverse variabile de mediu influen<?>eaza func<?>ionarea editorului de
       legaturi dinamice.

   Modul de ,,execu<?>ie securizata"
       Din motive de securitate, in cazul in care editorul de legaturi
       dinamice stabile<?>te ca un binar ar trebui sa fie executat in modul de
       execu<?>ie securizat, efectele anumitor variabile de mediu sunt anulate
       sau modificate <?>i, in plus, aceste variabile de mediu sunt eliminate
       din mediu, astfel incat programul nici macar nu vede defini<?>iile.
       Unele dintre aceste variabile de mediu afecteaza func<?>ionarea
       editorului de legaturi dinamice in sine <?>i sunt descrise mai jos.
       Alte variabile de mediu tratate in acest mod includ: 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.

       Un binar este executat in modul de execu<?>ie-securizata daca intrarea
       AT_SECURE din vectorul auxiliar (a se vedea getauxval(3)) are o valoare
       diferita de zero. Aceasta intrare poate avea o valoare diferita de zero
       din diverse motive, inclusiv:

       o  ID-urile de utilizator reale <?>i efective ale procesului difera,
          sau ID-urile de grup reale <?>i efective difera. Acest lucru se
          intampla de obicei ca urmare a executarii unui program set-user-ID
          sau set-group-ID.

       o  Un proces cu un ID de utilizator non-root a executat un binar care a
          conferit capacita<?>i procesului.

       o  Este posibil ca o valoare diferita de zero sa fi fost definita de un
          modul de securitate Linux.

   Variabile de mediu
       Unele dintre cele mai importante variabile de mediu sunt urmatoarele:

       LD_ASSUME_KERNEL (de la glibc 2.2.3 la glibc 2.36)
              Fiecare obiect partajat poate informa editorul de legaturi
              dinamice cu privire la versiunea ABI minima a nucleului de care
              are nevoie.  (Aceasta cerin<?>a este codificata intr-o
              sec<?>iune de nota ELF care poate fi vizualizata prin readelf -n
              ca o sec<?>iune etichetata NT_GNU_ABI_TAG). In momentul rularii,
              editorul de legaturi dinamice determina versiunea ABI a
              nucleului care ruleaza <?>i va respinge incarcarea obiectelor
              partajate care specifica versiuni ABI minime care depa<?>esc
              acea versiune ABI.

              LD_ASSUME_KERNEL poate fi utilizata pentru a determina editorul
              de legaturi dinamice sa presupuna ca ruleaza pe un sistem cu o
              versiune ABI de nucleu diferita. De exemplu, urmatoarea linie de
              comanda determina editorul de legaturi dinamice sa presupuna ca
              ruleaza pe Linux 2.2.5 atunci cand incarca obiectele partajate
              solicitate de prog-meu:

                  $ LD_ASSUME_KERNEL=2.2.5 ./prog-meu

              Pe sistemele care furnizeaza mai multe versiuni ale unui obiect
              partajat (in directoare diferite in ruta de cautare) care au
              cerin<?>e diferite privind versiunea ABI minima a nucleului,
              LD_ASSUME_KERNEL poate fi utilizata pentru a selecta versiunea
              obiectului care este utilizata (in func<?>ie de ordinea de
              cautare in directoare).

              Din punct de vedere istoric, cea mai frecventa utilizare a
              caracteristicii LD_ASSUME_KERNEL a fost selectarea manuala a
              implementarii mai vechi a firelor POSIX LinuxThreads pe
              sistemele care ofereau atat LinuxThreads, cat <?>i NPTL (aceasta
              din urma era de obicei op<?>iunea implicita pe astfel de
              sisteme); consulta<?>i pthreads(7).

       LD_BIND_NOW (incepand cu glibc 2.1.1)
              Daca este definita la un <?>ir de caractere nevid, determina
              editorul de legaturi dinamice sa rezolve toate simbolurile la
              pornirea programului, in loc sa amane rezolvarea apelurilor de
              func<?>ii pana in momentul in care acestea sunt referite pentru
              prima data.  Acest lucru este util atunci cand se utilizeaza un
              depanator.

       LD_LIBRARY_PATH
              O lista de directoare in care sa se caute biblioteci ELF la
              momentul execu<?>iei. Elementele din lista sunt separate fie
              prin doua puncte, fie prin punct <?>i virgula, <?>i nu exista
              suport pentru eludarea niciunui separator. Un nume de director
              de lungime zero indica directorul de lucru curent.

              Aceasta variabila este ignorata in modul de
              execu<?>ie-securizata.

              In cadrul numelor de rute specificate in LD_LIBRARY_PATH,
              editorul de legaturi dinamice extinde simbolurile $ORIGIN, $LIB
              <?>i $PLATFORM (sau versiunile care utilizeaza acolade in jurul
              numelor) a<?>a cum este descris mai sus in sec<?>iunea Simboluri
              dinamice de <?>ir. Astfel, de exemplu, urmatorul text ar face ca
              o biblioteca sa fie cautata fie in subdirectorul lib, fie in
              subdirectorul lib64 de sub directorul care con<?>ine programul
              care urmeaza sa fie executat:

                  $ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

              Observa<?>i utilizarea ghilimelelor simple, care impiedica
              extinderea $ORIGIN <?>i $LIB ca variabile shell!

       LD_PRELOAD
              O lista de obiecte partajate ELF suplimentare, specificate de
              utilizator, care urmeaza sa fie incarcate inaintea tuturor
              celorlalte. Aceasta caracteristica poate fi utilizata pentru a
              suprascrie selectiv func<?>ii din alte obiecte partajate.

              Elementele din lista pot fi separate prin spa<?>ii sau doua
              puncte <?>i nu exista suport pentru eludarea niciunui separator.
              Obiectele sunt cautate folosind regulile prezentate in
              sec<?>iunea DESCRIERE. Obiectele sunt cautate <?>i adaugate la
              tabelul de legaturi in ordinea de la stanga la dreapta
              specificata in lista.

              In modul de execu<?>ie securizata, numele de rute de
              preincarcare care con<?>in bare oblice (slashes) sunt ignorate.
              In plus, obiectele partajate sunt preincarcate numai din
              directoarele de cautare standard <?>i numai daca bitul de mod
              set-user-ID este activat (ceea ce nu este tipic).

              In cadrul numelor specificate in lista LD_PRELOAD, editorul de
              legaturi dinamice in<?>elege simbolurile $ORIGIN, $LIB <?>i
              $PLATFORM (sau versiunile care utilizeaza acolade in jurul
              numelor), astfel cum sunt descrise mai sus in Simboluri dinamice
              de <?>ir; (a se vedea, de asemenea, discu<?>ia despre punerea
              intre ghilimele in cadrul descrierii lui LD_LIBRARY_PATH).

              Exista diferite metode de specificare a bibliotecilor care
              urmeaza sa fie preincarcate, iar acestea sunt tratate in
              urmatoarea ordine:

              (1)  Variabila de mediu LD_PRELOAD.

              (2)  Op<?>iunea de linie de comanda --preload la apelarea
                   directa a editorului de legaturi dinamice.

              (3)  Fi<?>ierul /etc/ld.so.preload (descris mai jos).

       LD_TRACE_LOADED_OBJECTS
              Daca este definita (la orice valoare), face ca programul sa
              i<?>i listeze dependen<?>ele dinamice, ca <?>i cum ar fi rulat
              de ldd(1), in loc sa ruleze normal.

       Apoi, exista o mul<?>ime de variabile mai mult sau mai pu<?>in obscure,
       multe invechite sau doar pentru uz intern.

       LD_AUDIT (incepand cu glibc 2.4)
              O lista de obiecte ELF partajate, specificate de utilizator,
              care urmeaza sa fie incarcate inaintea tuturor celorlalte
              intr-un spa<?>iu de nume separat al editorului de legaturi (de
              exemplu, unul care nu intervine in legaturile normale de
              simboluri care ar aparea in proces) Aceste obiecte pot fi
              utilizate pentru a verifica func<?>ionarea editorului de
              legaturi dinamice. Elementele din lista sunt separate prin doua
              puncte <?>i nu exista suport pentru eludarea separatorului.

              LD_AUDIT este ignorata in modul de execu<?>ie-securizata.

              Editorul de legaturi dinamice va notifica obiectele partajate de
              audit la a<?>a-numitele puncte de control de audit - de exemplu,
              incarcarea unui nou obiect partajat, rezolvarea unui simbol sau
              apelarea unui simbol dintr-un alt obiect partajat - prin
              apelarea unei func<?>ii corespunzatoare in cadrul obiectului
              partajat de audit. Pentru detalii, consulta<?>i rtld-audit(7).
              Interfa<?>a de audit este in mare parte compatibila cu cea
              furnizata pe Solaris, a<?>a cum este descrisa in Linker and
              Libraries Guide, in capitolul Runtime Linker Auditing Interface.

              In cadrul numelor specificate in lista LD_AUDIT, editorul
              dinamic in<?>elege simbolurile $ORIGIN, $LIB <?>i $PLATFORM (sau
              versiunile care utilizeaza acolade in jurul numelor), astfel cum
              sunt descrise mai sus in Simboluri de <?>ir dinamice; (a se
              vedea, de asemenea, discu<?>ia despre punerea intre ghilimele in
              cadrul descrierii lui LD_LIBRARY_PATH).

              Incepand cu glibc 2.13, in modul de execu<?>ie securizata,
              numele din lista de audit care con<?>in bare oblice sunt
              ignorate <?>i sunt incarcate numai obiectele partajate din
              directoarele de cautare standard care au bitul de mod
              set-user-ID activat.

       LD_BIND_NOT (incepand cu glibc 2.1.95)
              Daca aceasta variabila de mediu este stabilita la un <?>ir
              nevid, nu se actualizeaza GOT (,,global offset table", tabelul
              de pozi<?>ii globale) <?>i PLT (,,procedure linkage table",
              tabelul de legaturi al procedurilor) dupa rezolvarea unui simbol
              de func<?>ie. Prin combinarea utilizarii acestei variabile cu
              LD_DEBUG (cu categoriile bindings <?>i symbols), se pot observa
              toate legaturile de func<?>ii in timpul execu<?>iei.

       LD_DEBUG (incepand cu glibc 2.1)
              Afi<?>eaza informa<?>ii de depanare detaliate despre
              func<?>ionarea editorului de legaturi dinamice.  Con<?>inutul
              acestei variabile este una sau mai multe dintre urmatoarele
              categorii, separate prin doua puncte, virgule sau (daca valoarea
              este pusa intre ghilimele) spa<?>ii:

              help        Specificand help in valoarea acestei variabile nu se
                          executa programul specificat <?>i se afi<?>eaza un
                          mesaj de ajutor despre categoriile care pot fi
                          specificate in aceasta variabila de mediu.

              all         Imprima toate informa<?>iile de depanare (cu
                          excep<?>ia statistics <?>i unused; a se vedea mai
                          jos).

              bindings    Afi<?>eaza informa<?>ii despre defini<?>ia la care
                          este legat fiecare simbol.

              files       Afi<?>eaza progresul pentru fi<?>ierul de intrare.

              libs        Afi<?>eaza rutele de cautare a bibliotecii.

              reloc       Afi<?>eaza procesarea realocarii.

              scopes      Afi<?>eaza informa<?>ii despre domeniul de aplicare.

              statistics  Afi<?>eaza statisticile privind realocarea.

              symbols     Afi<?>a<?>i rutele de cautare pentru fiecare simbol
                          cautat.

              unused      Determina DSO-urile neutilizate.

              versions    Afi<?>eaza dependen<?>ele de versiune.

              Incepand cu glibc 2.3.4, LD_DEBUG este ignorata in modul de
              execu<?>ie-securizata, cu excep<?>ia cazului in care exista
              fi<?>ierul /etc/suid-debug (con<?>inutul fi<?>ierului este
              irelevant).

       LD_DEBUG_OUTPUT (incepand cu glibc 2.1)
              In mod implicit, rezultatul LD_DEBUG este scris la ie<?>irea de
              eroare standard. Daca LD_DEBUG_OUTPUT este definita, atunci
              rezultatul este scris in numele de ruta specificat de valoarea
              sa, cu sufixul ,,." (punct) urmat de ID-ul procesului anexat la
              numele de ruta.

              LD_DEBUG_OUTPUT este ignorata in modul de execu<?>ie-securizata.

       LD_DYNAMIC_WEAK (incepand cu glibc 2.1.91)
              In mod implicit, atunci cand cauta in bibliotecile partajate
              pentru a rezolva o referin<?>a de simbol, editorul de legaturi
              dinamice va rezolva la prima defini<?>ie pe care o gase<?>te.

              Versiunile vechi ale glibc (inainte de glibc 2.2) aveau un
              comportament diferit: daca editorul de legaturi gasea un simbol
              slab, acesta re<?>inea acel simbol <?>i continua sa caute in
              bibliotecile partajate ramase. Daca, ulterior, se gasea o
              defini<?>ie puternica a aceluia<?>i simbol, atunci se folosea in
              schimb acea defini<?>ie; (daca nu mai gase<?>te niciun alt
              simbol, atunci editorul de legaturi dinamice utilizeaza simbolul
              slab pe care l-a gasit ini<?>ial).

              Comportamentul vechi al glibc nu era standard; (practica
              standard este ca distinc<?>ia dintre simbolurile slabe <?>i
              puternice ar trebui sa aiba efect numai la momentul legaturii
              statice). In glibc 2.2, editorul de legaturi dinamice a fost
              modificat pentru a oferi comportamentul actual (care era
              comportamentul oferit de majoritatea celorlalte implementari la
              acel moment).

              Definirea variabilei de mediu LD_DYNAMIC_WEAK (cu orice valoare)
              ofera vechiul comportament (nestandardizat) al glibc, prin care
              un simbol slab dintr-o biblioteca partajata poate fi anulat de
              un simbol puternic descoperit ulterior intr-o alta biblioteca
              partajata. Re<?>ine<?>i ca, chiar <?>i atunci cand aceasta
              variabila este definita, un simbol puternic dintr-o biblioteca
              partajata nu va trece peste o defini<?>ie slaba a aceluia<?>i
              simbol din programul principal.

              Incepand cu glibc 2.3.4, LD_DYNAMIC_WEAK este ignorata in modul
              de execu<?>ie-securizata.

       LD_HWCAP_MASK (de la glibc 2.1la glibc 2.38)
              Masca pentru capacita<?>ile hardware. Incepand cu glibc 2.26,
              op<?>iunea poate fi ignorata daca glibc nu accepta ,,tunables"
              (ajustari).

       LD_ORIGIN_PATH (incepand cu glibc 2.1)
              Ruta in care se gase<?>te binarul.

              Incepand cu glibc 2.4, LD_ORIGIN_PATH este ignorata in modul de
              execu<?>ie-securizata.

       LD_POINTER_GUARD (de la glibc 2.4 la glibc 2.22)
              Stabili<?>i valoarea 0 pentru a dezactiva protec<?>ia
              indicatorului. Orice alta valoare activeaza protec<?>ia
              indicatorilor, care este <?>i valoarea implicita. Protejarea
              indicatorilor este un mecanism de securitate prin care unii
              indicatori de cod stoca<?>i in memoria programului in care se
              poate scrie (adresele de retur salvate de setjmp(3) sau
              indicatorii de func<?>ie utiliza<?>i de diverse func<?>ii
              interne ale glibc) sunt modifica<?>i in mod semialeatoriu pentru
              a face mai dificil pentru un atacator sa deturneze indicatorii
              pentru a fi utiliza<?>i in cazul unui atac de tip ,,buffer
              overrun" (debordarea memoriei tampon) sau ,,stack-smashing"
              (zdrobirea stivelor). Incepand cu glibc 2.23, LD_POINTER_GUARD
              nu mai poate fi utilizat pentru a dezactiva protec<?>ia
              pointerilor, care este acum intotdeauna activata.

       LD_PROFILE (incepand cu glibc 2.1)
              Numele unui (singur) obiect partajat care urmeaza sa fie
              profilat, specificat fie ca nume de ruta, fie ca un soname.
              Rezultatul profilarii este anexat la fi<?>ierul al carui nume
              este: $LD_PROFILE_OUTPUT/$LD_PROFILE.profile.

              Incepand cu glibc 2.2.5, LD_PROFILE utilizeaza o ruta implicita
              diferita in modul de execu<?>ie-securizata.

       LD_PROFILE_OUTPUT (incepand cu glibc 2.1)
              Directorul in care ar trebui sa fie scrisa ie<?>irea LD_PROFILE.
              Daca aceasta variabila nu este definita sau este definita ca un
              <?>ir gol, atunci valoarea implicita este /var/tmp.

              LD_PROFILE_OUTPUT este ignorata in modul de
              execu<?>ie-securizata; in schimb, /var/profile este utilizat
              intotdeauna.

       LD_SHOW_AUXV (incepand cu glibc 2.1)
              Daca aceasta variabila de mediu este definita (cu orice
              valoare), se afi<?>eaza matricea auxiliara transmisa de nucleu
              (a se vedea <?>i getauxval(3)).

              Incepand cu glibc 2.3.4, LD_SHOW_AUXV este ignorata in modul de
              execu<?>ie-securizata.

       LD_TRACE_PRELINKING (de la glibc 2.4 la glibc 2.35)
              Daca aceasta variabila de mediu este definita, urmare<?>te
              pre-legatura obiectului al carui nume este atribuit acestei
              variabile de mediu; (utiliza<?>i ldd(1) pentru a ob<?>ine o
              lista a obiectelor care pot fi urmarite). Daca numele obiectului
              nu este recunoscut, atunci este urmarita toata activitatea de
              pre-legare.

       LD_USE_LOAD_BIAS (de la glibc 2.3.3 la glibc 2.35)
              In mod implicit (<?>i anume, daca aceasta variabila nu este
              definita), executabilele <?>i obiectele partajate pre-legate vor
              onora adresele de baza ale obiectelor partajate dependente, iar
              executabilele (ne=pre-legate) independente de pozi<?>ie (PIE)
              <?>i alte obiecte partajate nu le vor onora. Daca
              LD_USE_LOAD_BIAS este definita cu valoarea 1, atat
              executabilele, cat <?>i PIE-urile vor onora adresele de baza.
              Daca LD_USE_LOAD_BIAS este definita cu valoarea 0, nici
              executabilele, nici PIE-urile nu vor respecta adresele de baza.

              Incepand cu glibc 2.3.3, aceasta variabila este ignorata in
              modul de execu<?>ie-securizata.

       LD_VERBOSE (incepand cu glibc 2.1)
              Daca este definita la un <?>ir de caractere nevid, furnizeaza
              informa<?>ii despre versiunile simbolurilor despre program daca
              a fost definita variabila de mediu LD_TRACE_LOADED_OBJECTS.

       LD_WARN (incepand cu glibc 2.1.3)
              Daca este definita la un <?>ir nevid, avertizeaza cu privire la
              simbolurile nerezolvate.

       LD_PREFER_MAP_32BIT_EXEC (doar x86-64; incepand cu glibc 2.23)
              Conform ghidului de optimizare a software-ului Intel Silvermont,
              pentru aplica<?>iile pe 64 de bi<?>i, performan<?>a de
              predic<?>ie a ramificarii poate fi afectata negativ atunci cand
              <?>inta unei ramificari se afla la o distan<?>a mai mare de 4 Go
              de ramificare. Daca aceasta variabila de mediu este definita (la
              orice valoare), editorul de legaturi dinamice va incerca mai
              intai sa cartografieze paginile executabile utilizand fanionul
              mmap(2) MAP_32BIT <?>i va reveni la cartografierea fara acest
              fanion daca incercarea e<?>ueaza. NB: MAP_32BIT va face
              cartografierea catre cei 2 Go (nu 4 Go) ai spa<?>iului de
              adrese.

              Deoarece MAP_32BIT reduce intervalul de adrese disponibil pentru
              generarea aleatorie a spa<?>iului de adrese (ASLR),
              LD_PREFER_MAP_32BIT_EXEC este intotdeauna dezactivat in modul de
              execu<?>ie-securizata.

FI<?>IERE
       /lib/ld.so
              editor de legaturi/incarcator dinamic a.out

       /lib/ld-linux.so.{1,2}
              editor de legaturi/incarcator dinamic ELF

       /etc/ld.so.cache
              Fi<?>ier care con<?>ine o lista compilata de directoare in care
              sa se caute obiecte partajate <?>i o lista ordonata de obiecte
              partajate candidate. A se vedea ldconfig(8).

       /etc/ld.so.preload
              Fi<?>ier care con<?>ine o lista separata prin spa<?>ii albe de
              obiecte partajate ELF care urmeaza sa fie incarcate inainte de
              program. A se vedea discu<?>ia de mai sus despre LD_PRELOAD.
              Daca sunt utilizate atat LD_PRELOAD, cat <?>i
              /etc/ld.so.preload, bibliotecile specificate de LD_PRELOAD sunt
              preincarcate primele. /etc/ld.so.preload are un efect la nivelul
              intregului sistem, facand ca bibliotecile specificate sa fie
              preincarcate pentru toate programele care sunt executate pe
              sistem; (acest lucru este de obicei nedorit <?>i este utilizat
              de obicei numai ca remediu de urgen<?>a, de exemplu, ca o
              solu<?>ie temporara la o problema de configurare gre<?>ita a
              bibliotecilor).

              Translated with DeepL.com (free version)

       lib*.so*
              Obiecte partajate

NOTE
   Capacita<?>i Hardware vechi (de la glibc 2.5 la glibc 2.37)
       Unele obiecte partajate sunt compilate folosind instruc<?>iuni
       specifice hardware care nu exista pe fiecare CPU. Astfel de obiecte
       trebuie instalate in directoare ale caror nume definesc capacita<?>ile
       hardware necesare, cum ar fi /usr/lib/sse2/. Editorul de legaturi
       dinamice verifica aceste directoare in func<?>ie de hardware-ul
       ma<?>inii <?>i selecteaza cea mai adecvata versiune a unui anumit
       obiect partajat. Directoarele de capacita<?>i hardware pot fi puse in
       cascada pentru a combina caracteristicile CPU. Lista de nume de
       capacita<?>i hardware acceptate depinde de CPU. In prezent, sunt
       recunoscute urmatoarele nume:

       Alpha  ev4, ev5, ev56, ev6, ev67

       MIPS   loongson2e, loongson2f, octeon, octeon2

       PowerPC
              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

       SPARC  flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2

       s390   dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa,
              stfle, z900, z990, z9-109, z10, zarch

       x86 (doar 32-bi<?>i)
              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

       Suportul capacita<?>ilor hardware vechi are dezavantajul ca fiecare
       caracteristica noua adaugata mare<?>te exponen<?>ial ruta de cautare,
       deoarece trebuie sa fie adaugata la fiecare combina<?>ie a celorlalte
       caracteristici existente.

       De exemplu, pe x86 pe 32 de bi<?>i, daca hardware-ul accepta i686 <?>i
       sse2, ruta de cautare rezultata va fi i686/sse2:i686:sse2:..  O noua
       capacitate newcap va defini ruta de cautare la
       newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:.

   Capacita<?>i hardware glibc (de la glibc 2.33)
       glibc 2.33 a adaugat o noua schema de capacita<?>i hardware,
              in care, in cadrul fiecarei arhitecturi de procesor, pot fi
              definite anumite niveluri, care grupeaza suportul pentru anumite
              caracteristici sau instruc<?>iuni speciale. Fiecare nivel de
              arhitectura are un set fix de rute pe care le adauga la lista de
              cautare a editorului de legaturi dinamice, in func<?>ie de
              hardware-ul ma<?>inii. Deoarece fiecare nou nivel de arhitectura
              nu este combinat cu cele existente anterior, noua schema nu are
              dezavantajul cre<?>terii necontrolate a listei de cautare a
              editorului de legaturi dinamice.

       De exemplu, pe x86 pe 64 de bi<?>i, daca hardware-ul accepta x86_64-v3
       (de exemplu Intel Haswell sau AMD Excavator), ruta de cautare rezultata
       va fi glibc-hwcaps/x86-64-v3:glibc-hwcaps/x86-64-v2:. Urmatoarele rute
       sunt acceptate in prezent, in ordinea priorita<?>ilor.

       PowerPC (numai little-endian pe 64 de bi<?>i)
              power10, power9

       s390 (doar 64-b<?>i)
              z16, z15, z14, z13

       x86 (doar 64-bi<?>i)
              x86-64-v4, x86-64-v3, x86-64-v2

       glibc 2.37 a eliminat suportul pentru capacita<?>ile hardware
       mo<?>tenite(invechite).

CONSULTA<?>I <?>I
       ld(1), ldd(1), pldd(1), sprof(1), dlopen(3), getauxval(3), elf(5),
       capabilities(7), rtld-audit(7), ldconfig(8), sln(8)

TRADUCERE
       Traducerea in limba romana a acestui manual a fost facuta de Remus-
       Gabriel Chelu <remusgabriel.chelu@disroot.org>

       Aceasta traducere este documenta<?>ie gratuita; citi<?>i Licen<?>a
       publica generala GNU Versiunea 3
       <https://www.gnu.org/licenses/gpl-3.0.html> sau o versiune ulterioara
       cu privire la condi<?>ii privind drepturile de autor.  NU se asuma
       NICIO RESPONSABILITATE.

       Daca gasi<?>i erori in traducerea acestui manual, va rugam sa
       trimite<?>i un e-mail la <translation-team-ro@lists.sourceforge.net>.

Pagini de manual de Linux 6.12 6 decembrie 2024                       ld.so(8)