AI 요약
대부분의 실제 C 언어 프로젝트는 순수한 ISO C 표준만을 사용하기보다 컴파일러 간 버그와 기능 공백을 해결하기 위해 다양한 비표준 확장 기능에 의존하고 있습니다. 대안 컴파일러를 구축하려는 개발자는 GNU/Linux 환경에서 glibc 헤더인 sys/cdefs.h나 sys/epoll.h 등을 파싱하는 첫 단계부터 큰 난관에 봉착하게 됩니다. 특히 64비트 환경에서 ABI 호환성을 유지하기 위해 필수적인 __attribute__((packed))나 #include_next 같은 컴파일러 전용 확장은 GCC나 Clang이 아닌 타 컴파일러에서의 호환성을 깨뜨리기 일쑤입니다. 또한 컴파일러 자체적으로 제공해야 하는 내장 헤더들(stddef.h, limits.h 등)이 복잡하게 얽혀 있어, 독립적인 컴파일러 구현을 극도로 어렵게 만듭니다. SDL_endian.h 같은 외부 라이브러리들조차 GCC와 Clang에 맞춰 하드코딩된 탐지 로직을 사용하는 상황에서, C 컴파일러 생태계의 고착화와 이식성 저해 문제는 해결하기 어려운 과제로 남아 있습니다.
핵심 인사이트
- C 표준과 실제 코드의 괴리: 현실의 C 코드는 온전한 ISO C 표준을 따르기 어려우며, 대다수의 코드베이스가 컴파일러 우회용 비표준 확장에 의존하고 있습니다.
- 컴파일러 특정 내장 헤더 의존성: GCC 16.1.1(
/usr/lib/gcc/x86_64-pc-linux-gnu/16.1.1/include/) 및 Clang 22(/usr/lib/clang/22/include/)는 고유의 내장 헤더 디렉터리를 지니며, 시스템 라이브러리들은 이 특정 버전에 직접 결합되어 있습니다. - 특정 플랫폼 편향 설계:
SDL_endian.h와 같은 라이브러리는 최적화 기능을 위해 오직 GCC와 Clang만을 허용하도록 가드 조건문이 하드코딩되어 있어 타 대안 컴파일러의 진입을 원천 차단합니다.
주요 디테일
glibc내부의sys/cdefs.h는 컴파일러 사전에 정의된 매크로를 기반으로 지원되는 확장 기능을 제어하지만, GCC, Clang, TCC가 아닌 제3의 컴파일러에서는 제대로 빌드되지 않는 호환성 오류를 유발합니다.- Linux 전용 헤더인
sys/epoll.h내struct epoll_event구조체는 GNU 확장인__attribute__((packed))를 필수적으로 요구하며, 이를 무시하면 64비트 아키텍처에서 ABI 손상이 일어납니다. - POSIX 표준이 규정하는
limits.h를 구현하기 위해 glibc는 비표준 확장 기능인#include_next를 사용하여 GCC 내부의 한계값 매크로를 중첩해서 불러오는 복잡한 체인 구조를 취합니다. - 수많은 기성의 전처리기 가드(
#ifdef,#ifndef)는 시스템 이식성을 높이기 위해 고안되었으나, 실제 구현상의 미비로 인해 실질적으로 깨진 상태(broken)로 방치되는 경우가 허다합니다.
향후 전망
- 향후 시장에 등장할 새로운 대안 C 컴파일러들은 단순 표준 준수를 넘어, GCC와 Clang이 독점하고 있는 방대한 전처리기 확장 로직과 내장 함수들을 모두 시뮬레이션해야 하는 기형적인 개발 부담을 안게 될 것입니다.
- 이로 인해 컴파일러 생태계의 양극화가 가속화되고, 새로운 컴파일러의 출현이 억제되면서 컴파일러 기술 표준화의 실효성이 약화될 우려가 있습니다.
출처:hackernews