Puncte:12

De ce un binar construit 21.10 nu este compatibil cu instalarea 21.04?

drapel cn

Nu înțeleg de ce un binar construit pe 21.10 nu este compatibil cu un sistem 21.04.

Binarul este legat împotriva libc.so.6 care este disponibil și pe versiunea 21.04 OS.

Același binar, pe sistemul 21.10:

$ ldd turboledzd
    linux-vdso.so.1 (0x00007ffdc2595000)
    libhidapi-hidraw.so.0 => /lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 (0x00007fdd64057000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd63e2f000)
    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fdd63e06000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fdd64085000)

Și pe sistemul 21.04:

$ ldd turboledzd 
./turboledzd: /lib/x86_64-linux-gnu/libc.so.6: versiunea `GLIBC_2.34' nu a fost găsită (necesar de ./turboledzd)
    linux-vdso.so.1 (0x00007fff9c570000)
    libhidapi-hidraw.so.0 => /lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 (0x00007f37ec402000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37ec216000)
    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f37ec1ed000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f37ec423000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f37ec1cb000)

Intrebarea mea:

Dacă libc.so.6 din 21.04 nu este compatibil cu libc.so.6 de la 21.10, atunci de ce nu este apelat libc pe 21.10 libc.so.7 in schimb?

Sau, mai bine, de ce nu este legat de ceva numit libglibc.so.2.34 - dacă asta este o dependență?

N0rbert avatar
drapel zw
Utilizați 20.04 LTS dacă doriți să obțineți o durată lungă de viață fără probleme pentru aplicația dvs.
marcelm avatar
drapel cn
_"Sau, mai bine, de ce nu este legat de ceva numit libglibc.so.2.34"_ - Cum crezi că ar ajuta asta? În ambele cazuri, programul nu va rula până când nu instalați un glibc actualizat.
drapel cn
tl;dr: Da, este o mizerie stupidă. Dacă nu ar fi, atunci nu ar fi Linux. Pentru comparație, imaginați-vă cât de prost ar fi dacă un program pe care l-ați compilat pe Windows 10 20H2 nu ar rula pe Windows 10 20H1.
drapel cn
@user541686: Nu este specific pentru Linux; este un rezultat al moștenirii AT&T comune a Unix și Linux.Mai exact, `libc` este tratat ca parte a sistemului de operare. Pe Windows, `MSVCRT*.DLL` face parte din Visual Studio, nu Windows, iar mai multe versiuni pot coexista. Alte compilatoare pentru Windows pot livra în mod similar propriile biblioteci. API-ul Windows în sine este puternic versat în SDK-ul său și a fost cel puțin de la Windows 95.
Puncte:25
drapel us

Dacă libc.so.6 din 21.04 nu este compatibil cu libc.so.6 de la 21.10, atunci de ce nu este apelat libc pe 21.10 libc.so.7 in schimb?

libc.so este o bibliotecă la fel de centrală pe cât vin. Aproape totul depinde de asta. Unul dintre obiectivele glibc este acela de a oferi compatibilitate inversă - un program care ar putea rula cu un program mai vechi libc.so.6 ar trebui (de obicei) să funcționeze bine și cu o versiune mai nouă. Totuși, dacă dai peste soname libc.so.7 doar pentru că ai adăugat o funcție nouă, atunci toate dintre aceste programe construite anterior vor avea nevoie de o reconstrucție fără un motiv întemeiat. Nu a existat un cu adevărat major întreruperea API-ului pentru ca glibc să garanteze acest lucru încă.

Nu înțeleg de ce un binar construit pe 21.10 nu este compatibil cu un sistem 21.04.

Nu văd pe nimeni garantând înainte compatibilitate (care a fost ceea ce vă așteptați până în 21.04, fiind capabil să rulați ceva din 21.10) - de ce v-ați aștepta la asta dacă nu vă luați măsuri de precauție pentru a vă asigura?

drapel st
Glibc a fost la versiunea 6 a bibliotecii de când fac Linux, dacă îmi amintesc bine.
muru avatar
drapel us
Din [1997, când s-a încheiat separarea Linux libc/glibc](https://man7.org/linux/man-pages/man7/glibc.7.html), se pare.
Bram avatar
drapel cn
Deci, nu construiți niciodată nimic pe un sistem nou, atunci, dacă doriți să distribuiți un binar? Cum pot folosi un sistem de operare nou pentru a construi binare care rulează și pe sisteme de operare mai vechi?
Incomputable avatar
drapel cn
@Bram, puteți rămâne cu un set de caracteristici pe care îl oferă cea mai veche bibliotecă din sistemele de operare de distribuție.
Bram avatar
drapel cn
@Incomputable Nu folosesc nicio caracteristică nouă. Folosesc un nou sistem de operare pentru a compila.
Guntram Blohm avatar
drapel cn
Acesta este motivul pentru care păstrez o mașină virtuală Fedora 12 de peste 10 ani (ar putea fi la fel de bine Ubuntu 10.04, dar am trecut la Ubuntu doar cu 14.04); Orice instrument mic pe care îl creez pentru uzul meu este compilat acolo și funcționează pe fiecare mașină pe care îl copiez, indiferent cât de vechi sau nou este.
Ruslan avatar
drapel bv
@Bram da, pur și simplu nu-l compilați pe un sistem mai nou decât cea mai veche țintă a dvs. și, de asemenea, nu utilizați GCC mai nou decât ținta suportă, cel puțin pentru codul C++, deoarece `libstdc++.so` va avea exact aceeași problemă .
Ruslan avatar
drapel bv
@Incomputable nu este ușor cu glibc/libstdc++, deoarece atunci când conectați, utilizați automat cel mai recent ABI suport pentru aceste biblioteci, cum ar fi `GLIBC_2.34` în OP, iar acest lucru este cerut de binarul final să fie prezent în biblioteca pe care o încarcă la pornire. Poate că există ceva magic linker de făcut altfel, dar nu sunt conștient de asta.
drapel cn
@Bram „Cum pot folosi un nou sistem de operare pentru a construi binare” - docker ajută foarte mult în situații ca aceasta. Puteți folosi imaginea `ubuntu:20.04`, de exemplu, să mapați directorul sursă în interiorul acestuia și să construiți fișierele binare acolo. Vă salvează instalarea unui glibc / crosscompiling separat.
drapel cn
@viraptor Ar fi util să explici ce s-ar putea face fără Docker. Această problemă este veche, dar Docker a apărut abia în 2013.
drapel cn
@user541686 fără el răspunsul este dureros și prea lung pentru comentarii. „Google pentru a afla despre instalarea mai multor lanțuri de instrumente și compilarea încrucișată” este cel mai scurt indicator.
capr avatar
drapel cn
Oamenii Linux pur și simplu nu pot înțelege de ce cineva ar dori să construiască un binar care să funcționeze pe un sistem mai vechi. Și au avut _zeci de ani_ să înțeleagă lucruri simple ca acestea și încă nu le înțeleg.
muru avatar
drapel us
@capr și ce te oprește să faci asta?
capr avatar
drapel cn
Simbolurile versionate ale lui @muru glibc „funcție” și lipsa opțiunii de compatibilitate pentru „versiunea minimă” a lui gcc (cum are OSX).
muru avatar
drapel us
@capr ah, dar construirea pentru versiuni mai vechi este o problemă rezolvată - chiar și acum 7-8 ani, când m-am interesat în ambalaje, pbuilder și altele asemenea erau deja un flux de lucru matur. În zilele noastre, cu Docker este și mai ușor. Nu sunt un tip macOS, așa că nu știu dacă macOS are echivalente pentru *acea*.
capr avatar
drapel cn
@muru faptul că îmi recomanzi să construiesc cu Docker, deci tot pe un Linux mai vechi doar că acum este într-un VM arată tocmai lipsa de înțelegere a problemei despre care vorbeam. Pe un Linux mai vechi ai un vechi gcc! Nu asta vrei deloc. E doar un hack. Este opusul ingineriei.
muru avatar
drapel us
@capr eh, cu Docker, puteți face cu ușurință o imagine cu vechiul dvs. glibc și noul GCC. Tot ceea ce văd aici este o lipsă de interes în utilizarea soluțiilor bine cunoscute și bine înțelese și, în schimb, pur și simplu mă plâng când lucrurile nu stau ca $MY_FAVOURITE_OS
capr avatar
drapel cn
@muru, așa că, pentru a reveni la întrebarea dvs. inițială, ceea ce mă „oprește” să fac acest lucru este să nu vreau să construiesc o mașină virtuală și să construiesc întregul lanț de instrumente al compilatorului și, în afară de a face asta, „mă plâng”, am înțeles.
Puncte:13
drapel us

Conform packages.ubuntu.com, 21.04 folosește glibc 2.33, în timp ce 21.10 utilizează glibc 2.34, care nu sunt complet compatibile.

Cu toate acestea, ar trebui să puteți construi fișiere binare pentru Ubuntu 21.04 din codul sursă.

Cu excepția cazului în care sursa este interpretată, de obicei trebuie să construiți pachete binare separat pentru diferite versiuni de Ubuntu. Platforma de lansare poate automatiza asta pentru tine.

de ce libc-ul din 21.10 nu se numește libc.so.7?

Aceasta este o decizie pe care numai dezvoltatorii glibc o pot lua.

drapel cn
Este o decizie pe care un distribuitor ar putea să o ia, cred - dar probabil ar provoca mult mai multă confuzie și incompatibilitate decât ar rezolva... Și dacă doriți cu adevărat un sistem cu mai multe versiuni glibc, probabil că trebuie să aveți versiunea ld -linux.so... care ar trebui să se reflecte în binarele pentru un astfel de sistem, făcându-le incompatibile cu aproape orice altceva...
Puncte:2
drapel ph

Termenul pentru care trebuie căutat pe Google este „versiune simbol glibc”.

La fel de această introducere explică, glibc conține mai multe versiuni ale fiecărui simbol care s-a schimbat de-a lungul timpului și așadar libc.so.6 conține toate versiunile glibc de la 2.0 până la orice versiune spune.

Când conectați o nouă bibliotecă sau un binar cu acesta, utilizați .h fișiere și simboluri exportate pentru cele mai noi versiuni ale simbolurilor.

În ceea ce privește accesarea simbolurilor mai vechi, există o întrebare pe StackOverflow numită Cum pot conecta la o anumită versiune glibc?, dar pentru că toate celelalte dependențe sunt probabil să se conecteze și cu cele mai noi simboluri, este mult mai ușor să utilizați Docker sau un chroot pentru a viza versiuni mai vechi de sistem, deoarece probabil veți ajunge să construiți unul de la zero dacă nu o faceți.

Dezvoltatorii Python mențin de fapt containerele Docker numite multelinux... special pentru stabilirea unei linii de bază fiabile pentru construirea de roți (pachete binare redistribuibile) pentru pachetele Python cu componente compilate.

Cred că abordarea Windows este mai aproape de a grupa mai multe profiluri clar definite și de a îndemna toți autorii bibliotecilor precompilate să ofere versiuni care vizează profiluri mai vechi. (Cu avertismentul că trebuie să vă asumați aceste lucruri trebuie sa fi liberd de aceeaşi unitate de compilare care mallocAș fi, deoarece PE nu are simboluri globale și biblioteci diferite pot depinde de diferite versiuni ale alocătorului cu propriile lor static variabile și diferențe semantice.)

drapel cn
**Windows** are într-adevăr mai multe profiluri clar definite și încă le documentează înapoi la NT 4.0: https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt . Dar nu presupune nimic despre `malloc/free`; acestea nu sunt funcții Windows. Windows folosește `HeapAlloc`/`HeapFree` și necesită doar să utilizați același heap pentru ambele.
drapel ph
@MSalters Indiferent dacă utilizați API-ul Win32 sau API-ul POSIX, ideea mea a fost că documentația Microsoft pe care am citit-o a luat o atitudine foarte „Dacă se rupe, puteți păstra piesele” față de alocarea într-o singură construcție a artefactului și eliberarea în altul... doar nu-mi cere să-l găsesc din nou. Era era WinXP și de atunci Microsoft și-a remanierat adresele URL și a re-temat MSDN-ul.
drapel cn
Documentația Microsoft despre MSVC avea acele avertismente - compilatorul implementează `malloc`, desigur.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.