glibc가 GCC와 별도로 유지 관리되는 이유는 무엇입니까?

GCC는 C 컴파일러입니다. Glibc는 C 라이브러리입니다. 그러나 컴파일러와 표준 라이브러리가 C 구현으로 함께 번들로 제공되어야합니까?

예를 들어, C 라이브러리 등 ABI 및 컴파일러 특정 물건을 포함 <limits.h>, <stdint.h>등, 컴파일러와 API 간의 어느 다르다. "주 함수를 호출하는 방법"과 같은 세부 사항은 컴파일러에 따라 다르지만 실제로는 이러한 세부 사항이 libc.soLinux 시스템에서 제공됩니다 . 예를 들어, int8 바이트와 같이 다른 ABI와 함께 작동하도록 컴파일러를 변경하면 C 라이브러리는 더 이상 작동하지 않습니다 <limits.h>.

이유 중 하나는 GCC 를 자체 C 표준 라이브러리가있는 시스템 (예 : MacOSX, Solaris, HPUX 또는 일부 FreeBSD와 같은 독점 Unix 시스템)에서 빌드하고 사용할 수 있기 때문입니다 .

Linux에서도 GNU Glibc 가 아닌 C 표준 라이브러리를 사용할 수 있습니다 . 특히 musl-libc 또는 Bionic (Android 시스템) 또는 dietlibc 등이있는 Linux 시스템에서 GCC를 빌드하거나 사용할 수 있습니다. Linux 시스템은 GNU Glibc를 사용하고 Clang 과 같은 다른 C 컴파일러를 사용할 수 있습니다. 또는 TinyCC).

또한 C 라이브러리는 Linux 커널에 크게 의존합니다. 일부 이전 버전의 커널에는 특정 종류 (또는 버전)의libc

그리고 GCC는 크로스 컴파일러 로 빌드 할 수 있습니다.

" main함수 호출 방법"과 같은 세부 사항 도 컴파일러에 따라 다르지만 실제로는 이러한 세부 사항이 libc.soLinux 시스템에서 제공됩니다 .

정확하지 않습니다. 이 main함수는 crt0에 의해 (호스팅 된 환경에서) 호출되며 , 그 중 일부는 GCC에서 제공합니다 (예 : /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o내 Debian / Sid / x86-64는 libgcc-6-dev패키지에서 제공). 에 대해 읽기libgcc

실제로, libc많은 libc헤더가 (선택적으로) 일부 gcc 내장 또는 함수 속성을 사용 하기 때문에 GCC와 GCC 간에 약간의 숨겨진 관계가 있습니다.

^{(따라서 GCC 개발자와 GNU libc 개발자는 상호 작용해야합니다)}

.... 다른 ABI와 작동하도록 컴파일러를 변경하면 ...

/configureGCC 컴파일러 가 필요합니다. GCC 컴파일러를 다시 빌드해야하며, ABI 및 호출 규칙 을 설명하기 위해 GCC 컴파일러 를 패치 해야 할 수도 있습니다 . X32 ABI는 좋은 예입니다.

마지막으로, GCC (나를 포함하여)의 공헌자 또는 관리자는 GCC에 대해서는 저작권이 있지만 GNU에는 해당되지 않는 저작권에 서명했습니다 glibc.

^{(GCC 라이센스에 대해서는 GCC 런타임 라이브러리 예외를 주의 깊게 읽으십시오 )}

GCC 와 같은 <limits.h>또는 일부 표준 헤더 <stdint.h>는 GCC에서 제공합니다. <stdlib.h>GCC 빌드 중에 "고정 된" 것과 같은 다른 것들도있다 : 컴파일러 빌드 절차는 그것들을 Libc 구현에서 가져 와서 패치한다. 여전히 다른 표준 헤더 (아마도 <stdio.h>포함 된 내부 헤더)는에서 가져옵니다 libc. GCC FIXINCLUDES 및 고정 헤더 파일 에 대해 자세히 알아보십시오 .

^{(수정 사항은 내가 (Basile) 여전히 이해하지 못하는 것입니다.)}

gcc -v -H어떤 실제 프로그램이 실행되는지 ( gcc드라이버, cc1컴파일러, ld& collect2링커, as어셈블러 등) 실행되는 헤더와 포함 된 헤더, 링크 된 라이브러리 및 오브젝트 파일 (더욱 정확한 프로그램)을보다 정확하게 이해하기 위해 컴파일 할 수 있습니다. C 표준 라이브러리 및 crt0을 포함하여 암시 적으로 ). GCC 옵션 에 대해 자세히 알아보십시오 .

BTW, 당신은 적절한 추가 인수를 우회 하여 GCC가 기대하거나 빌드 한 것과 다른 C 표준 라이브러리를 사용할 수 있습니다 (예 : musl-libc일부 Dietlibc ) gcc.

짧은 대답은 둘이 함께 묶여 있다면 glibc는 GPL *에 따라 라이센스가 부여되므로 독점 프로젝트에는 적합하지 않다는 것입니다. FSF와 GNU 프로젝트는 독점 소프트웨어를 좋아하지 않지만 glibc는 LGCC의 라이센스를 받아 GCC와 자유 소프트웨어 생태계의 채택을 진전시키기위한 전략적 선택으로 라이센스를 받았습니다. GCC는 실제로 특정 런타임 연결 예외와 함께 GPL에 따라 라이센스가 부여됩니다. 상황은 다소 흐릿합니다. glibc는 합리적인 공유 라이브러리 상황을 허용하기 위해 LGPL에 따라 라이센스가 부여됩니다.

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

또한 glibc는 다양한 운영 체제에 적용 할 수있는 모든 종류의 심 및 기타 구성 요소를 가지고 있으며 gcc와 동일한 패키지로 배포하면 문제가 발생할 수 있습니다.

* 대안 적으로, GCC는 다른 GPL 하에서 라이센스를받을 수 있지만, FSF의 생각은 "나의 시체를 넘어선"줄에있을 것입니다.