Frissen ismerkedem a C-vel - legalábbis Linuxon... :) Egy nagyon-nagyon alap kérdésem lenne, a linkeléssel kapcsolatban.
- Miért kell/ajánlott újrafordítani egy programot glibc, ill. uClibc használatakor, ha ugyanazokat a hívásokat használnám? Ahogy én tudom a program indításakor meghatározza a függőségeket, és a hívási címeket hozzárendeli a függvényekhez. Avagy csak a libc speciális eset?
- BSD esetén számomra még furább jelenséggel találkoztam... Miért kell minden kiadáshoz újrafordítani a szoftvereket? Amennyire tudom, ott azért nem annyira sűrűen változnak az egyes függvényhívások, paraméterek... Mi történik akkor, ha linuxos binárist futtatnék FreeBSD Linux kompatibilitási rétegén?
Aki rászán a szabadidejéből és felhomályosít, vagy irányt mutat ( elsőként :) ) , és Debrecenben jár vendégem egy sörre ... :D
Előre is köszönöm! :)
Hozzászólások
subscribe
A glibc/uClibc eseteben sztem azert, mert a hivasi cimek elternek a ket libc eseteben - hiszen az osztott konyvtar merete se ugyanakkora. Illetve egyebkent sem art, mert a uClibc-ben par dolog ugy tudom nincs benne, pont ezert tud kicsi lenni. De persze en nem ertek hozza, csak elovettem a logikat.
--
Csak egy példa: független libc implementációk egymástól függetlenül alakíthatják ki a szabványos struktúrák tartalmát is (pl.
). Betehetnek extra mezőket, más pakolást írhatnak elő a fordítónak pragmákkal stb. Amíg a két oldal (a futtatható és a shared lib) azonos deklaráció alapján lett fordítva, vagyis a mezők írására-olvasására használt offset-ek azonosak a két oldalon, addig nincs gond, egyébként meg szétdől minden.
Az uClibc-nel nincs garancia ra, hogy ket verzio binarisan kompatibilis, ha uClibc verziot valtasz, minden programot ujra kell forditani:
uClibc does not even attempt to ensure binary compatibility across releases.
When a new version of uClibc is released, you may or may not need to recompile
all your binaries.
Itt megtalalod a glibc es uClibc kozotti kulonbsegeket.
Köszi, tetszett az olvasmány.
freebsd-nel azert, mert minden freebsd verzional libc major-t bumpolnak (ellentetben netbsd-vel pl)
--
NetBSD - Simplicity is prerequisite for reliability
Es ez miert jo/nem jo? Ennyit valtoztatnak?
--
ha azert nem jo, amiert a topic nyito irta :-)
azert jo, mert nem kell teljesen kompatibilisnek lenni a libc-nek
--
NetBSD - Simplicity is prerequisite for reliability
Köszönöm a válaszokat! Látom ez már többfős sörözés lesz, mindenki adott infót. :)
Ahogy középiskolai kémia tanárom mondta (nyugodjék meg):"Naszóvaltehátakkortulajdonképpen" ... hagy foglaljam össze:
Normál esetben, ha két glibc verzió közt csak hibajavítás történt, és nincs adattípus és/vagy függvényhívás eltérés, a rá írt binárisok gond nélkül futhatnak. glibc vs uclibc esetén hasonló okok miatt kell az újrafordítás a megfelelő headerekkel.
Ha jól olvastam az LSB lenne hivatott valamelyest csökkenteni a divergenciát az egyes terjesztések közt (egységes ABI-ra).
BSD esetén még mindig nem világos teljesen. A "bumpolnak" terminológia ismeretlen számomra :)
====================================================================
#include "alairas.h"
Version bump: a verzio valamely komponensenek novelese.
--
ugye van egy elf libed az altalaban igy nez ki:
libsheldon.1.2.3, itt az 1 a major, 2 a minor es 3 a subminor.
major-t akkor illik bumpolni (azaz egyel novelni), ha az ABI valtozott (tehat nem binarisan kompatibilis)
persze sok gnukoder gyakran semmibe veszi ezeket az ajanlasokat es random verzioznak, amibol az lesz, hogy semmi nem indul el, amit egy evnel regebbi linuxra forditottal :p
--
NetBSD - Simplicity is prerequisite for reliability
<troll>Jah, bezzeg FreeBSD-n faszan fut akar a ket major verzioval ezelott forditott cucc is!</troll>
--
|8]
Akkor már csak a "végső" kérdésem maradt. :)
Mi a helyzet a kernel rendszerhívásokkal? Azok is olyan gyorsan változnak?
.. mert így az okok alapján számomra úgy tűnik, hogy lehetséges több eltérő libc-vel statikusan linkelt program futtatása.
... avagy ha vállalom, hogy közvetlen hívom a kernel egy korlátozott mennyiségű hívásait, elméletben lehetséges olyan bináris, ami a legtöbb linux alatt (+freebsd linux layer) szépen futna ...
====================================================================
#include "alairas.h"
Az attol fugg, milyne kernel hivasrol van szo. Illetve szerintem a freebsd linux layer kernelt nem emulal, tehat azt felejtsd el. Az csak arra valo, hogy egy linuxra forgatott pl. Oracle RDBMS-nek egyaltalan eselye legyen elindulni - es ez se garantal semmit. Kernelt biztos nem kapsz.
--
Értem, köszi! :) Azt olvastam a docban hogy a FreeBSD linux API layer csak a hívásokat forgatja át FBSD -re. Nekem az is megfelel, ha működik :)
.. viszont legalább már tudom, hogy honnan kezdjek el elindulni :)
====================================================================
#include "alairas.h"
1. Általános alkalmazásnál statikus libc-vel nem jutsz messzire, kivéve néhány speciális esetet. Hint: libnsl/libnss - ezeket nem fogod tudni használni, mivel ők nem tudnak statikusak lenni, viszont garantáltan gondjaid lesznek, ha random régebbi statikusan linkelt glibc mellé megpróbálod dinamikusan berántani ezeket - mert jön velük az aktuális dinamikus glibc is, és a két különböző verziójú glibc egy programnak tuti meg fog ártani!
2. Linuxon, glibc-vel tőkéletesen működik az, hogy lefordítod/linkeled valami verzióval, és ha nem csináltál nagy hülyeséget, akkor ez nagyon sokáig el fog futni a későbbi verziókon is. Mivel nem szokásuk inkompatibilis módon változtatni a felületet.
3. A kernel hívásokat nem akarod direktben használni. Arra van a glibc. Nem mintha ezek sűrűn változnának...
Hmm. Kapizsgálom :-)
[elmélkedés on]
Ezek szerint amikor az USB_MODESWITCH binárisa reklamált a glibc verzió miatt, és újra kellett fordítani, akkor az inkább a programozó miatt lehetett, mintsem maga a technológia.
[elmélkedés off]
====================================================================
#include "alairas.h"
Az siman elkepzelheto, hogy ujabb glibc kellett neki, mint ami neked volt. Ilyenkor sirni fog. Ha regebbi glibc kell neki, mint ami neked van, es sir, akkor ott valaki valamit nagyon elkefelt (es valoszinuleg nem a glibc oldalon).
--
|8]
Hat igen, glibc-ben eleg regen volt mar inkompatibilis api/abi change. Egyszer volt, tudom, akkor gentoo-n mindent ujra kellett forgatni, na az cink volt.
--