Skip to main content

Cyber AI România

Duminică, 20 septembrie 2026

readelf, objdump și dynamic loader: cum diagnostichezi rapid erorile „library not found” și executabilele incompatibile în Linux

În Linux, multe erori care par misterioase au de fapt o cauză foarte clară: programul nu găsește biblioteca de care are nevoie, caută un simbol care nu există în versiunea instalată sau pur și simplu nu este compatibil cu arhitectura sistemului. Vestea bună este că nu ai nevoie de ghicit. Cu readelf, objdump și cu informațiile oferite de dynamic loader poți înțelege rapid unde se rupe lanțul.

Primul lucru util este să separi tipul problemei. Dacă vezi mesaje de tipul „cannot open shared object file” sau „library not found”, discuția începe de obicei de la dependențe și de la căile în care loaderul caută bibliotecile. Manualul ld.so explică faptul că, pentru binarele ELF, linkerul dinamic încarcă bibliotecile necesare și le caută într-o ordine clară: intrări precum DT_RPATH sau DT_RUNPATH, variabila LD_LIBRARY_PATH dacă nu e blocată de modul securizat, cache-ul /etc/ld.so.cache și apoi directoarele implicite precum /lib, /usr/lib, respectiv variantele lor pe 64 de biți.

Aici readelf devine una dintre cele mai curate unelte. Cu readelf -d poți vedea secțiunea dinamică și intrările NEEDED, RPATH sau RUNPATH, adică exact ce biblioteci declară binarul și dacă are căi de căutare incluse. Cu readelf -l verifici și program headers, inclusiv interpreterul ELF din secțiunea .interp, adică loaderul așteptat de executabil. Dacă programul indică un loader nepotrivit sau absent, eroarea nu mai pare deloc misterioasă.

Pentru un control rapid al dependențelor directe, objdump -p este foarte util. Chiar manualul ldd recomandă objdump -p | grep NEEDED ca alternativă mai sigură atunci când lucrezi cu executabile în care nu ai încredere deplină. Motivul este important: documentația ldd avertizează că unele implementări pot ajunge să execute cod atunci când încearcă să afle dependențele unui fișier, așa că nu este o idee bună să rulezi ldd pe binare necunoscute doar din curiozitate.

Al doilea scenariu frecvent este „undefined symbol” sau lipsa unor simboluri la pornire. Aici nu mai este suficient să știi că biblioteca există; trebuie să verifici dacă exportă exact simbolul sau versiunea de simbol cerută de aplicație. readelf –dyn-syms și readelf -s ajută la inspectarea tabelelor de simboluri, iar readelf -V arată informații despre versioning. Dacă aplicația cere o versiune de simbol care nu apare în bibliotecă, problema nu este calea greșită, ci nepotrivirea dintre binar și biblioteca instalată. În același registru, ldd -r poate raporta obiecte sau funcții lipsă la faza de relocare, ceea ce este util în medii controlate și de încredere.

Al treilea caz este executabilul incompatibil. Aici readelf -h oferă indiciile de bază: clasa ELF, 32 sau 64 de biți, tipul de date, ABI-ul și câmpul e_machine. Manualul elf(5) descrie aceste elemente direct din antetul ELF. Dacă rulezi un binar ELFCLASS64 pe un sistem sau într-un mediu care așteaptă altă clasă ori altă arhitectură, eroarea nu ține de o bibliotecă lipsă, ci de incompatibilitatea fișierului în sine. Tot readelf este preferat în astfel de verificări pentru că citește structura ELF în detaliu și independent de biblioteca BFD, așa cum arată documentația GNU Binutils.

În practică, o ordine bună de diagnostic este simplă. Mai întâi verifici antetul cu readelf -h, ca să vezi dacă fișierul se potrivește sistemului. Apoi te uiți la interpreter și segmente cu readelf -l. După aceea verifici dependențele și căile cu readelf -d sau objdump -p. Dacă biblioteca există, dar aplicația tot nu pornește, treci la simboluri și versioning cu readelf –dyn-syms și readelf -V. Iar dacă vrei confirmarea modului în care linkerul rezolvă efectiv dependențele într-un mediu sigur, poți compara rezultatele cu ldd.

Pe scurt, aceste unelte nu repară singure problema, dar scot imediat la suprafață cauza reală. În loc să reinstalezi la întâmplare pachete sau să copiezi biblioteci din surse incerte, poți afla dacă lipsește o dependență, dacă simbolul cerut nu este exportat sau dacă executabilul nici măcar nu se potrivește cu platforma pe care încerci să-l rulezi. Pentru administratori, dezvoltatori și utilizatori avansați, asta înseamnă mai puțin timp pierdut și mai puține „soluții” riscante.

Surse

Facebook
X
WhatsApp
readelf, objdump și dynamic loader: cum diagnostichezi rapid erorile „library not found” și executabilele incompatibile în Linux

Te-ar putea interesa si: