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

13

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.

Michael Tsang
la source

Réponses:

20

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...

Basile Starynkevitch
la source
1
Bonne réponse, même si ce n'est pas une conception correcte. C'est pourquoi MSVC ++ peut compiler du code C ++ 11 / C ++ 14 pour les systèmes d'exploitation antérieurs à 2011/2014, mais GCC ne le peut généralement pas.
MSalters
Qu'entendez-vous par «pas une conception correcte»? Et je ne suis pas sûr que GCC ne puisse pas compiler le code C ++ 14 pour les anciens OS (cependant, vous devrez peut-être compiler un GCC récent sur cet ancien OS).
Basile Starynkevitch,
Selon ISO C, la bibliothèque standard C fait partie du compilateur. Il en va de même pour la bibliothèque C ++. Maintenant, le problème est que les applications créées avec une nouvelle version de GCC auront une dépendance à la glibc du système d'exploitation où elles sont construites, qui peut être plus récente que la glibc sur le système cible. Une meilleure solution aurait probablement reposé sur une gcclibcqui s'appuie sur les bibliothèques de système d'exploitation, mais est versionnée dans le cadre de GCC et non du système d'exploitation.
MSalters
Êtes-vous sûr que les normes C11 ou C ++ 14 mentionnent le mot "compilateur"? AFAIU ils parlent de "mise en œuvre" (qui pourrait même ne pas être un logiciel)
Basile Starynkevitch
1
Certains en-têtes, comme <stdint.h>ou <limits.h>sont en effet fournis par GCC. D'autres en-têtes, comme <stdlib.h>un extrait de la bibliothèque C et "corrigé" lors de la construction de GCC.
Basile Starynkevitch
-5

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".

comment s'appelle-t-il
la source
3
Désolé, mais cette réponse est à mon humble avis erronée. Le «regroupement» n'implique pas que la glibc soit une «œuvre dérivée» de GCC au sens décrit dans la GPL. Par exemple, des tonnes de packages logiciels utilisant différentes licences open source sont "regroupés" dans chaque distribution Linux, néanmoins ces packages ne violent pas la GPL.
Doc Brown
Pourquoi le regroupement de gcc et de glibc obligerait-il Glibc à être sous GPL? Ma compréhension était que les bundles ne sont pas un "travail combiné", donc la GPL ne franchit pas la frontière. Edit: ce que Doc Brown a dit :-)
Philip Kendall