커널에는 인터럽트와 매직 넘버를 기반으로 하는 API가 있습니다. 이 API는 너무 낮은 수준이고 프로그래머에게 친숙하지 않아서 libcs가 발명되었습니다. 커널 API를 직접 호출하는 편의 함수를 노출합니다.
사실 1: Linux 커널 API는 매우 안정적이므로 이전 musl에 정적으로 연결되는 애플리케이션에서는 이전 커널 API 동작이 여전히 유효할 것으로 예상할 수 있습니다.
사실 2: 정적 링크가 애플리케이션에 연결되어 전체 애플리케이션이 커널 API를 직접 호출할 수 있습니다.
사실 3: 정적으로 링크된 musl로 컴파일된 애플리케이션은 베어 커널 API만 사용하여 Linux의 현재 및 향후 버전에서 실행됩니다.
그렇다면 일부 배포판에서는 왜 명시적인 musl 지원이 있습니까? Linux 호환 커널 API만 있으면 충분하지 않나요?
내 질문에 답할 수 없기 때문에 내 "사실" 중 일부는 유효하지 않은 것 같습니다.
답변1
세 가지 사실은 최소한 C 라이브러리(상위 수준)에 필요한 것이 무엇인지 이해할 만큼 정확합니다.
내가 생각하기에 유효하지 않은 것은 "명시적인 musl 지원"에 대한 귀하의 이해입니다. 가지다세 가지 유형의 분포musl의 관점에서 보면:
- Alpine과 같이 소프트웨어 전체 또는 대부분을 빌드하기 위해 musl을 C 라이브러리로 사용하는 배포판은 설치 크기를 줄이기 위해 수행되는 경우가 많습니다(musl은 GNU C 라이브러리보다 훨씬 작기 때문입니다).
- 배포가 없습니다내장머슬러를 지원하세요;
- 사용자에게 musl을 서비스로 제공하지만 이에 의존하지 않는 배포판입니다.
다른 바이너리와 마찬가지로 필요한 라이브러리도 제공하는 한 모든 Linux 배포판에서 musl 종속 바이너리를 사용할 수 있습니다. 정적으로 링크된 경우 라이브러리를 제공할 필요가 없습니다. 배포 자체에는 특별한 요구 사항이 없습니다.
위의 세 번째 유형에 대해 궁금하실 수도 있습니다. musl에 의존하지 않는 배포판에 musl을 제공하는 것은 musl을 사용하여 바이너리를 빌드하려는 사용자가 더 쉽게 만들 수 있도록 하기 위한 것입니다. 이러한 배포판은 musl 라이브러리(일반적으로 정적 및 동적), 헤더 파일 및 필요한 컴파일러 지원을 제공합니다. musl을 사용하여 바이너리를 빌드합니다. 즉, 사용자는 musl을 설치하고 컴파일러를 직접 구성하지 않고도 musl을 사용하여 바이너리 구축을 시작할 수 있습니다.
일반적으로 일부 배포판은 특정 기능을 지원하고 다른 배포판은 해당 기능을 지원하지 않는다는 의미는 아니며 최종 사용자가 관련 작업을 수행해야 함을 의미합니다.