¿Por qué glibc se mantiene separado de GCC?

GCC es el compilador de C. Glibc es la biblioteca de C. Sin embargo, ¿no es una necesidad absoluta para un compilador y la biblioteca estándar agrupados como una implementación de C?

Por ejemplo, la biblioteca C contiene ABI y específica compilador cosas por el estilo <limits.h>, <stdint.h>etc., que difiere entre los compiladores y las API. Y detalles como "cómo llamar a una función principal" también dependen del compilador, pero de hecho esos detalles son proporcionados por libc.soun sistema Linux. Por ejemplo, si cambio el compilador para que funcione con otro ABI, como usarlo intcon 8 bytes, la biblioteca C ya no funcionará porque las cosas <limits.h>se volverán incorrectas.

Una de las razones es que GCC puede ser construido y utilizado en (por ejemplo, sistemas Unix propietarios como algunos de FreeBSD MacOSX, Solaris, HPUX o) sistemas que tienen su propia biblioteca estándar C .

Incluso en Linux, puede tener una biblioteca estándar C que no sea GNU Glibc . En particular, puede construir GCC (o usarlo) en sistemas Linux con musl-libc o con Bionic (sistemas Android) o con dietlibc , etc. Y un sistema Linux podría tener GNU Glibc y usar algún otro compilador de C (como Clang o TinyCC).

Además, la biblioteca C depende en gran medida del núcleo de Linux. Algunas versiones antiguas del núcleo pueden requerir algún tipo particular (o versión) delibc

Y GCC se puede construir como un compilador cruzado .

Y detalles como "cómo llamar a una mainfunción" también dependen del compilador, pero de hecho, esos detalles los proporciona libc.soun sistema Linux.

Eso no es exactamente correcto. La mainfunción se llama (en un entorno alojado) por el material crt0 , parte del cual es proporcionado por GCC (por ejemplo, /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.oen mi Debian / Sid / x86-64 es del libgcc-6-devpaquete). Lea también sobrelibgcc

En realidad, existe una relación medio oculta entre libcy GCC, por ejemplo, porque muchos libcencabezados están (opcionalmente) utilizando algunos atributos incorporados de gcc o funciones .

^{(por lo tanto, los desarrolladores de GCC y los desarrolladores de GNU libc tienen que interactuar)}

.... si cambio el compilador para que funcione con otro ABI ...

Deberá ... /configurecompilar el GCC y reconstruirlo, e incluso podría necesitar parchear el compilador GCC (para describir su ABI y las convenciones de llamadas ). El x32 ABI es un buen ejemplo.

Finalmente, algunos contribuyentes o mantenedores de GCC (incluido yo) han firmado una asignación de derechos de autor que cubre GCC pero no el GNU glibc.

^{(con respecto a la licencia de GCC, lea cuidadosamente la excepción de la biblioteca de tiempo de ejecución de GCC )}

Tenga en cuenta que algunos encabezados estándar, como <limits.h>o <stdint.h>son proporcionados por GCC; otros, como <stdlib.h>son "arreglados" durante la compilación de GCC: el procedimiento de compilación del compilador los toma de la implementación de Libc y los aplica parches. Aún así, otros encabezados estándar (probablemente <stdio.h>y los encabezados internos que incluye) se toman del libc. Lea más sobre GCC FIXINCLUDES y los archivos de encabezado fijo .

^{(La solución incluye algo que yo (Basile) todavía no entiendo bien)}

Puede compilar gcc -v -Hpara comprender con mayor precisión qué programas reales se ejecutan (ya que gcces un controlador, ejecuta el cc1compilador, los ld& collect2linkers, el asensamblador, etc.) y qué encabezados están incluidos, qué bibliotecas y archivos de objetos están vinculados (incluso implícitamente, incluyendo la biblioteca estándar C y el crt0 ). Lea más sobre las opciones de GCC .

Por cierto, puede usar una biblioteca estándar C diferente de la que su GCC espera o para la que fue creada (por ejemplo, musl-libco alguna dietlibc ), omitiendo los argumentos adicionales apropiados para gcc...

La respuesta corta es que si los dos se 'agruparan', glibc se licenciaría bajo la GPL *, y por lo tanto sería completamente inadecuado para proyectos propietarios. Si bien el proyecto FSF y GNU no ama el software propietario, glibc recibió licencia LGPL como una opción estratégica para avanzar en la adopción de GCC y el ecosistema de software libre. En realidad, GCC tiene licencia bajo la GPL con una excepción específica de enlace de tiempo de ejecución, porque la situación es algo turbia. glibc tiene licencia según la LGPL para permitir situaciones sensibles de biblioteca compartida.

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

Además, glibc tiene todo tipo de cuñas y otros componentes para adaptarlo a diferentes sistemas operativos, y distribuirlo como el mismo paquete que gcc también complicaría las cosas.

* Alternativamente, GCC podría licenciarse bajo otra GPL, aunque los pensamientos de la FSF sobre eso estarían en la línea de "sobre mi cadáver".