Miért tartják fenn a glibc-t az ÖET-től külön?
A GCC a C fordító. Glibc a C könyvtár. Nem feltétlenül szükséges azonban, hogy a fordító és a standard könyvtár együtt legyen C megvalósításként?
Például a C könyvtár ABI-t és fordítóspecifikus dolgokat tartalmaz
Ennek egyik oka, hogy a GCC saját C szabványos könyvtárával rendelkező rendszereken felépíthető és használható (pl. Saját Unix rendszerek, például MacOSX, Solaris, HPUX vagy néhány FreeBSD rendszer) .
Még Linuxon is rendelkezhet egy szabványos C könyvtárral, amely nem GNU Glibc. Különösen létrehozhat (vagy használhat) GCC-t Linux rendszereken musl-libc vagy Bionic (Android rendszerek) vagy dietlibc stb. Egy Linux rendszerben lehet GNU Glibc, és más C fordítót használhat (például Clang vagy TinyCC).
Ezenkívül a C könyvtár nagymértékben függ a Linux kerneltől. A kernel néhány régi verziójához szükség lehet egy bizonyos típusú libc-re (vagy verzióra)
És az olyan részletek, mint a "Hogyan hívjuk meg a fő funkciót", szintén a fordítótól függenek, de valójában ezeket a részleteket a libc.so nyújtja egy Linux rendszernek. .
Ez nem egészen helyes. A fő funkciót (hosztolt környezetben) a crt0 dolgokból hívják meg, amelyek egy részét a GCC biztosítja (pl. /Usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o a Debian-on/Sid/x86-64 a libgcc-6-dev csomagból származik). Olvassa el a libgcc-t is
Valójában félig rejtett kapcsolat van a libc és a GCC között, pl. B. mert sok libc fejléc (opcionális) használ néhány GCC beépített vagy funkció attribútumot .
(Ezért a GCC fejlesztőknek és a GNU libc fejlesztőknek kölcsönhatásba kell lépniük.)
. amikor megváltoztatom a fordítót egy másik ABI-vel való együttműködésre .
Neked kell . A/configure telepíti és újjáépíti a GCC fordítót, sőt előfordulhat, hogy javítania kell a GCC fordítót (az ABI és a hívási konvenciók leírására). Az x32 ABI jó példa.
Végül néhány GCC közreműködő vagy fenntartó (köztük én is) aláírt egy szerzői jogi közleményt, amely lefedi az GCC-t, de nem a GNU glibc-t .
(A GCC licencért olvassa el figyelmesen a GCC futásidejű könyvtár kivételét.)
Vegye figyelembe, hogy néhány szabványos fejléc, például vagy az ÖET nyújtja. mások, például például, a GCC felépítése során "rögzítettek": a fordító felépítési eljárása elveszi őket a libc implementációból és kijavítja őket. Más szabványos fejlécek (valószínűleg és az azokban található belső fejlécek) a libc-ből származnak. További információ a GCC FIXINCLUDES és a Fix fejlécfájlokról .
(A javítással kapcsolatos dolog magában foglal valamit, amit én (Basile) még mindig nem nagyon értek.)
Összeállíthat a gcc -v -H paranccsal, hogy jobban megértsük, milyen programok futnak (mivel a gcc olyan illesztőprogram, amely futtatja a cc1 fordítót, az ld & collect2 linkereket, mint assembler stb.) és mely fejlécek szerepelnek benne, mely könyvtárak és objektumfájlok vannak összekapcsolva (jelenleg) implicit módon, beleértve a C szabványos könyvtárat és a crt0-t is). További információ az ÖET-opciókról .
Egyébként használhat egy szabványos C könyvtárat, amely eltér attól, amit a GCC vár, vagy amire létrehozták (pl. Musl-libc vagy diétás könyvtár), miközben megkerüli a megfelelő további argumentumokat a gcc létrehozásához .