Зошто glibc се одржува одделно од GCC

GCC е компајлерот C. Глибц е библиотека Ц. Сепак, не е апсолутно неопходно компајлерот и стандардната библиотека да бидат спакувани како С имплементација?

На пример, библиотеката C содржи ABI и специфични работи за компајлери, како што се

, итн., што е помеѓу компајлерите и API-те. И деталите како „како да се повика главна функција“, исто така, зависат од компајлерот, но всушност овие детали се обезбедени од libc.so на систем за Linux. На пример, ако го сменам компајлерот да работи со различен ABI, како што е int со 8 бајти, библиотеката C ќе престане да работи затоа што податоците

не се во право.

Една од причините е што GCC може да се гради и да се користи на системи со своја C стандардна библиотека (на пр. Сопственички системи Unix како MacOSX, Solaris, HPUX или некои системи на FreeBSD) .

Дури и на Linux, можете да имате стандардна библиотека C што не е GNU Glibc. Особено, можете да креирате (или да користите) GCC на Linux системи со musl-libc или со Bionic (Android системи) или со dietlibc итн. Линукс-системот може да има GNU Glibc и да користи различен компајлер C (како Clang или TinyCC).

Покрај тоа, библиотеката C е во голема мера зависна од јадрото на Linux. Некои стари верзии на јадрото може да бараат одреден тип (или верзија) на libc

И деталите како „како да се повика главна функција“, исто така, зависат од компајлерот, но всушност овие детали се обезбедени од libc.so на Linux систем .

Тоа не е точно. Главната функција е повикана (во домаќин на опкружување) од нештата crt0, од кои некои се обезбедени од GCC (на пр. /Usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o на мојот Debian/Sid/x86-64 е од пакетот libgcc-6-dev). Прочитајте и за libgcc

Всушност, постои полускриена врска помеѓу libc и GCC, на пр. Б. бидејќи многу наслови на libc (по избор) користат некои вградени GCC или атрибути на функциите .

(Оттука, развивачите на GCC и развивачите на GNU libc треба да комуницираат.)

. кога ќе го сменам компајлерот за работа со различен АБИ .

Ти треба да ./конфигурирање ќе го инсталира и реконструира компајлерот GCC, па можеби ќе треба дури и да го закрпите компајлерот GCC (за да ги опишете вашите АБИ и конвенции за повици). X32 ABI е добар пример.

Конечно, некои соработници или одржувачи на ГЦЦ (вклучително и јас) потпишаа известување за авторски права што го опфаќа ГЦЦ, но не и ГНУ ГЛИБЦ .

(За лиценцата на GCC, внимателно прочитајте го исклучокот за библиотека за траење на GCC.)

Забележете дека некои стандардни заглавија, како на пр или обезбедени од ГЦЦ. други, како на пример, се „фиксираат“ за време на изградбата на GCC: постапката за градење компајлери ги зема од имплементацијата на libc и ги коригира. Другите стандардни заглавија (веројатно и внатрешните заглавија што ги содржат) доаѓаат од libc. Прочитајте повеќе за GCC FIXINCLUDES и фиксни датотеки со заглавија .

(Работата за поправка вклучува нешто што јас (Басилеј) сè уште не го разбирам многу добро.)

Може да компајлирате со gcc -v -H за подобро да разберете кои реални програми се извршуваат (бидејќи gcc е двигател што ги извршува компајлерот cc1, ld & collect2 линкери, како асемблер, итн.) и кои заглавија се вклучени, кои библиотеки и датотеки со предмети се поврзани (моментално) имплицитно, вклучително и стандардната библиотека C и crt0). Повеќе информации за опциите на ГЦЦ .

Патем, можете да користите стандардна библиотека C што е различна од онаа што ја очекува вашиот ГЦЦ или е создадена (на пр. Musl-libc или диетална библиотека), заобиколувајќи ги соодветните дополнителни аргументи за да направите gcc .