Informații utilizator pentru unix glibc

Biblioteca C este una dintre cele mai importante componente ale fiecărui sistem Unix, deoarece este, de asemenea, responsabilă pentru interacțiunea fără întrerupere a aplicației și a procesului de server.







Mai departe veți găsi câteva indicații și informații suplimentare, în care vom descrie pe scurt modul în care putem recunoaște,

  • Scanerul antivirus instalat nu este în conflict cu mediul procesorului
  • unde să mergeți în cazul unei actualizări incomplete.

Aproape toate componentele sistemului Unix (OS în sine, programele de sistem și majoritatea tuturor aplicațiilor) sunt scrise direct în limba de programare C sau sunt construite pe componentele scrise în C.

Funcțiile de bază pe care se bazează aplicațiile în munca lor sunt, de obicei, așa-numitele libc. Aceasta include lucrul cu fișierele RAM, cu rețeaua, gestionarea proceselor și accesul la toate serviciile create de sistemul de operare.

Este logic ca aceste funcții să nu fie stocate permanent de fiecare program și să nu fie trimise. Prin urmare, acestea sunt instalate în locația centrală a sistemului și sunt disponibile pentru toate celelalte programe. Deoarece sistemul Unix acceptă conceptul de biblioteci disponibile (comparabile cu fișiere DLL pe alte platforme), este obișnuit să distribuim aplicațiile corespunzătoare sub forma unor așa-numite binare legate dinamic. Sistemul de operare de bază furnizează numai biblioteca C asociată în momentul pornirii programului.

Prin urmare, este imposibil să evitați situațiile în care există, atunci există neconcordanțe cu standardul. Uneori chiar "în coajă" obținem o imagine omogenă și consistentă, dar în zone mai complexe, abaterile pot duce la faptul că aplicațiile folosite trebuie să corespundă condițiilor modificate. Consecințele semanticii schimbate pot fi astfel încât, de exemplu, o interfață care interpretează datele într-un anumit mod este utilizată în mod neașteptat în alte procese de procesare. Poate o altă consecință: Interfețele datorate modificării parametrilor lor își schimbă imaginea și principiul de acțiune, deoarece funcționalitatea lor a fost extinsă.

Din aceste motive, biblioteca are o denumire clară a versiunii (stadiul actual al dezvoltării și, prin urmare, caracteristica acesteia). Cu toate acestea, nu toate versiunile folosite sunt compatibile "în toate direcțiile".

De obicei, o versiune mai mare este compatibilă cu versiunea mai veche. Această compatibilitate este garantată (dacă este garantată) numai pentru versiunile conexe. Cu alte cuvinte: în sensul deplin al cuvântului, compatibilitatea nu este capabilă de tranziții mari.

Deci, ce faci? Dacă există surse ale sistemului de operare și ale aplicațiilor, puteți efectua conversia întregului sistem pentru a obține o stare compatibilă și compatibilă. Dacă aplicațiile sunt descărcate ca binare, trebuie să alegeți versiunea corectă atunci când descărcați. Atunci când actualizați componentele principale, ar trebui să acordați atenție faptului că componentele unei versiuni mai mari au o dependență și, dacă este necesar, pot fi actualizate. Dacă, de exemplu, o componentă importantă a sistemului, cum ar fi libc, modifică sau actualizează o versiune superioară, este posibil să fie necesar să actualizați nu numai sistemul subiacent, ci și întregul software de aplicație.

Determinarea versiunii bibliotecii sau a versiunilor suportate de AntiVir

S-ar putea suna ciudat: Din motive de compatibilitate și interacțiune cu un sistem deschis, o aplicație care rulează nu poate cunoaște versiunea instalată a libc-ului și, prin urmare, poate determina dacă poate funcționa în acest mediu. Definiția versiunii prin forma bibliotecii nu este furnizată deloc (cu toate acestea, dacă există implementări care au această funcție, această metodă nu va funcționa mult timp pe toate sistemele sau pe toate platformele). În același timp, în acest caz, vorbim despre problema binecunoscută a ouălor și a puiului: Cum - atunci când versiunile necesare și disponibile sunt impermanente - ar trebui lansată o aplicație nefuncțională și apoi testată performanța ei?







Din păcate, noi, dezvoltatorii de software, nu putem rezolva în prezent această dilemă și îi ușurăm pe utilizatori să lucreze așa cum ar dori. Situația descrisă mai sus necesită ca administratorul rețelei să monitorizeze constant starea compatibilă a software-ului instalat, această sarcină nu va fi efectuată pentru nimeni de nimeni. Cu toate acestea, am dori să oferim un ghid pentru identificarea și rezolvarea problemelor.

remediu

Următoarele instrucțiuni se bazează pe sistemul de operare Linux cu biblioteca GNU-C. Bineînțeles. pentru alte platforme, aspectele de mai sus funcționează, dar până acum numai în Linux și împreună cu GNU libc există o cerință urgentă de a alege una dintre versiunile propuse.

Biblioteca glibc se află pe un hard disk într-un format care vă permite să îl utilizați ca un "program obișnuit". Acest lucru ajută nu numai în faza de dezvoltare, ci vă permite, de asemenea, să afișați informații esențiale mai târziu, atunci când le primiți.

/lib/libc.so.6 | cap -1

arată numărul versiunii (informațiile furnizate sunt mult mai extinse, totuși în acest caz numai linia cu numărul versiunii este filtrată). Dacă această comandă afișează un mesaj "Permisiune respinsă" sau fișierul nu pornește ca un "program" din alt motiv, puteți încerca să îl porniți cu următoarea comandă:

/lib/ld-linux.so.2 /lib/libc.so.6 | cap -1

Dacă numărul versiunii începe cu 2.0 sau 2.1, puteți utiliza arhivele marcate cu glibc20 ale software-ului nostru. Dacă numărul versiunii începe cu 2.2 sau 2.3, ar trebui să utilizați arhivele marcate cu glibc22. Desigur, libc poate fi de asemenea cu versiunea (internă) 1 și în acest caz are numele fișierului libc.so.5. Deși această implementare nu este relevantă și are puține funcții, datorită volumului său mic (nu există o internaționalizare) este adesea folosită în sistemele încorporate, adică unde este nevoie de economie de spațiu și nu se pune problema actualizării.

În plus față de versiunea GNU libc, sunt utilizate și alte implementări care urmăresc obiective diferite, precum "flexibilitate" sau "mobilitate extremă". Din moment ce utilizarea acestui software este rezultatul deciziilor conștiente (și nu "aleatorie" sau din cauza instalării unei distribuții standard), pornim de la faptul că administratorii cunosc foarte bine sistemul lor. Acestea respectă prevederile discutate aici și știu exact care bibliotecă glibc este cea mai potrivită pentru implementarea utilizată. Prin urmare, ei știu care arhivă de software H + BEDV ar trebui să fie utilizate.

În cazuri rare, atunci când fișierul cu implementarea libc nu se află în directorul lib, administratorul ar trebui să știe unde este localizat fișierul. În cazul controversat, încărcătorul din sistemul de funcționare știe unde sunt obiectele deschise. Dacă aveți îndoieli, puteți folosi comanda

ldd / bin / ls (sau orice alt program legat dinamic)

și căutați liniile care utilizează libc (sau ldlinux pentru cazul descris mai sus cu o bibliotecă care nu pornește ca un program).

Programele externe "au logică la nivel înalt pentru aplicație, în timp ce accesează funcții de nivel inferior, la componente ale sistemului, cum ar fi libc. Dacă aceste componente sunt în conflict, software-ul nu va funcționa corect (și paleta de efecte se va schimba de la "lucru aparent" la "lucru uneori, dar de multe ori nu funcționează", atunci "nu funcționează deloc, nu se întâmplă nimic" , din acest motiv părul meu cade și pisica mea mă urăște ").

Software-ul aplicației nu poate efectua un test de compatibilitate satisfăcător, în urma căruia administratorul trebuie să fie responsabil pentru compatibilitatea și funcționarea sistemului. Deoarece versiunile Linux ale software-ului nostru sunt oferite în diferite versiuni pentru diferite medii, trebuie să faceți o alegere bazată pe biblioteca C instalată.

Calea completă către fișierul bibliotecă C instalată de pe hard disk și versiunea implementării pe care o utilizați pot fi găsite utilizând următoarele comenzi:

$ ldd / bin / ls / bin / bash / usr / bin / vi
/ bin / ls:

librt.so.1 => /lib/librt.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40030000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40160000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

libncurses.so.5 => /lib/libncurses.so.5 (0x4001e000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40066000)
libdl.so.2 => /lib/libdl.so.2 (0x4006c000)
libperl.so.1 => /usr/lib/libperl.so.1 (0x4006f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4016f000)
libutil.so.1 => /lib/libutil.so.1 (0x4019c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4019f000)
libm.so.6 => /lib/libm.so.6 (0x401f0000)
libc.so.6 => /lib/libc.so.6 (0x40213000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ /lib/libc.so.6 | cap -1
Biblioteca GNU C Versiunea stabilă a versiunii 2.3.1 de către Roland McGrath și colab.

În funcție de biblioteca CL instalată pentru programe, trebuie să utilizați arhivele software corespunzătoare H + BEDV. În mod obișnuit, programele noastre antivirus sunt executate pentru Linux, astfel încât acestea să funcționeze cu GNU-libc în versiunile 2.2 sau 2.3. Pentru sistemele care sunt limitate în resursele lor sau în cazul în care libc5 este utilizat din alte motive, versiunile corespunzătoare sunt, de asemenea, disponibile. Administratorii care nu utilizează implementarea GNU în sistemele lor ar trebui să aleagă cea mai potrivită arhivă.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: