Pourquoi la glibc est maintenue séparément de GCC?

GCC est le compilateur C. Glibc est la bibliothèque C. Cependant, n'est-ce pas une nécessité absolue pour un compilateur et la bibliothèque standard regroupés en tant qu'implémentation C?

Par exemple, la bibliothèque C contient des choses spécifiques ABI et du compilateur comme <limits.h>, <stdint.h>, etc., qui diffère entre les compilateurs et les API. Et des détails comme "comment appeler une fonction principale" dépendent également du compilateur, mais en fait, ces détails sont fournis par libc.sosur un système Linux. Par exemple, si je modifie le compilateur pour qu'il fonctionne avec un autre ABI, comme intavec 8 octets, la bibliothèque C ne fonctionnera plus car le contenu <limits.h>deviendra incorrect.

L' une des raisons est que GCC peut être construit et utilisé sur (par exemple les systèmes Unix propriétaires comme MacOSX, Solaris, HPUX ou certains FreeBSD) systèmes ayant leur propre bibliothèque standard C .

Même sous Linux, vous pouvez avoir une bibliothèque standard C qui n'est pas la GNU Glibc . En particulier, vous pouvez construire GCC (ou l'utiliser) sur des systèmes Linux avec musl-libc ou avec Bionic (systèmes Android) ou avec dietlibc , etc. Et un système Linux pourrait avoir la GNU Glibc et utiliser un autre compilateur C (comme Clang ou TinyCC).

De plus, la bibliothèque C dépend fortement du noyau Linux. Certaines anciennes versions du noyau peuvent nécessiter un type (ou une version) particulier delibc

Et GCC est compilable en tant que compilateur croisé .

Et des détails comme "comment appeler une mainfonction" dépendent également du compilateur, mais en fait, ces détails sont fournis par libc.sosur un système Linux.

Ce n'est pas tout à fait exact. La mainfonction est appelée (dans un environnement hébergé) par le truc crt0 , dont certains sont fournis par GCC (par exemple /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.osur mon Debian / Sid / x86-64 est du libgcc-6-devpaquet). Lisez aussilibgcc

En fait, il existe une relation à moitié cachée entre libcet GCC, par exemple parce que de nombreux en- libctêtes utilisent (facultativement) des commandes internes ou des attributs de fonction gcc .

^{(d'où les développeurs GCC et les développeurs GNU libc doivent interagir)}

.... si je change le compilateur pour qu'il fonctionne avec un autre ABI ...

Vous devrez ... /configurele compilateur GCC et le reconstruire, et vous pourriez même avoir besoin de patcher le compilateur GCC (pour décrire votre ABI et les conventions d'appel ). L' ABI x32 en est un bon exemple.

Enfin, certains contributeurs ou mainteneurs de GCC (dont moi) ont signé une cession de copyright qui couvre GCC mais pas GNU glibc.

^{(concernant la licence GCC, lisez attentivement l' exception de la bibliothèque d'exécution GCC )}

Notez que certains en-têtes standard, comme <limits.h>ou <stdint.h>sont fournis par GCC; d'autres, comme <stdlib.h>sont "fixes" lors de la construction de GCC: la procédure de compilation du compilateur les prend de l'implémentation de Libc et les corrige. Pourtant, d'autres en-têtes standard (probablement <stdio.h>et les en-têtes internes qu'il inclut) sont tirés du libc. En savoir plus sur GCC FIXINCLUDES et les fichiers d'en-tête fixes .

^{(le correctif inclut quelque chose que je (Basile) ne comprends toujours pas bien)}

Vous pouvez compiler avec gcc -v -Hpour comprendre plus précisément quels programmes réels sont exécutés (puisqu'il gccs'agit d'un pilote, exécutant le cc1compilateur, les ld& collect2linkers, l' asassembleur, etc ...) et quels en-têtes sont inclus, quelles bibliothèques et fichiers objets sont liés (même implicitement, y compris la bibliothèque standard C et le crt0 ). En savoir plus sur les options GCC .

BTW, vous pouvez utiliser une bibliothèque standard C différente de celle à laquelle votre GCC s'attend ou a été conçue (par exemple, musl-libcou un peu de dietlibc ), en contournant les arguments supplémentaires appropriés pour gcc...

La réponse courte est que si les deux étaient «groupés» ensemble, la glibc serait licenciée sous la GPL *, et elle serait donc totalement inadaptée aux projets propriétaires. Alors que le projet FSF et GNU n'aime pas les logiciels propriétaires, glibc a obtenu la licence LGPL comme choix stratégique pour faire avancer l'adoption de GCC et de l'écosystème du logiciel libre. GCC est en fait sous licence GPL avec une exception de liaison d'exécution spécifique, car la situation est quelque peu boueuse. glibc est autorisé par la LGPL pour permettre des situations sensibles de bibliothèque partagée.

https://www.gnu.org/licenses/gcc-exception-faq.html

De plus, glibc a toutes sortes de cales et d'autres composants pour l'adapter à différents systèmes d'exploitation, et distribuer cela comme le même package que gcc rendrait également les choses désordonnées.

* Alternativement, GCC pourrait être autorisé sous quelque chose d'autre GPL, bien que les réflexions de la FSF à ce sujet soient dans le sens de "Over my dead body".