Google 개발자는 LLVM용 자체 libc 개발을 제안했습니다.

Google의 개발자 중 한 명 제기 LLVM 프로젝트의 일부로 다중 플랫폼 표준 C 라이브러리(Libc) 개발에 관한 LLVM 메일링 리스트에 있습니다. 여러 가지 이유로 Google은 현재 libc(glibc, musl)에 만족하지 않으며 LLVM의 일부로 개발되도록 제안된 새로운 구현을 개발하는 중입니다.

LLVM 개발은 최근 Google의 어셈블리 도구 구축을 위한 기반으로 사용되었습니다. 주요 아이디어는 Google이 이미 libc 개발을 시작했다면 자체 C++(Libc++)용 표준 라이브러리를 이미 제공하지만 유사한 C용 표준 라이브러리는 없는 LLVM의 일부로 시스템을 즉시 개발하는 것이 어떻겠습니까? (libc).

개발은 단계적으로 진행되어 점차적으로 기능이 향상될 예정입니다. 첫 번째 옵션은 아직 구현되지 않은 기능을 차용하는 애플리케이션과 시스템 Libc 사이의 계층으로 설계되도록 제안되었습니다. 특정 수준의 기능에 도달한 후에는 새로운 Libc를 시스템 Libc의 완전한 대체품으로 사용할 수 있습니다. x86-64 아키텍처, Linux, 정적 링크 지원부터 시작할 계획입니다(동적 로딩, 링크 및 추가 아키텍처는 부차적으로 구현될 예정입니다).

이 프로젝트는 아직 개발 초기 단계에 있지만 기본 목표는 이미 정의되었습니다.

• 모놀리식 세트가 아닌 세분화된 라이브러리를 제공한다는 철학에 따른 모듈화 및 개발
• 모드의 정적 링크 지원 PIE (위치 독립적 실행 파일) 및 PIE가 없습니다. 정적으로 링크된 실행 파일을 위한 CRT(C 런타임) 및 PIE 로더 제공
• POSIX 추가 및 기존 애플리케이션에 필요한 일부 시스템별 확장을 통해 대부분의 표준 C 라이브러리 기능을 지원합니다.
• 공급업체별 확장에 주의하고 필요한 경우에만 추가하세요. 타사 확장 지원과 관련하여 Clang 및 libc++ 프로젝트의 접근 방식을 사용하는 것이 제안됩니다.
• 처음부터 새니타이저 및 퍼지 테스트를 사용하는 등 LLVM 툴킷을 사용하여 개발 시 모범 사례를 사용합니다.

활동적인 LLVM 개발자 중 한 명 지시 된libc를 LLVM 툴킷의 일부로 제공하는 것이 합리적이라는 것은 분명하지만 일반적으로 그러한 필요가 발생할 때 잘 작성되고 다양한 아키텍처를 지원하며 동적 지원을 포함하여 필요한 기능을 제공하는 musl 라이브러리를 사용합니다. 연결. musl을 LLVM에 내장하고 이를 메인 프로젝트와 동기화된 포크로 개발하는 것이 타당할 수 있습니다.

당신의 의견도 표현 된 Google의 제안과 LLVM 배포판에 Libc를 포함시키는 것이 왜 매우 나쁜 생각인지 주장하려는 Musl 프로젝트의 저자는 다음과 같습니다.

• 정확하고 호환 가능하며 고품질의 Libc를 개발하고 유지하는 것은 매우 어려운 작업입니다. 문제는 코드의 양에 있는 것이 아니라 C/C++로 작성된 애플리케이션의 거대한 계층과 런타임이 사용되는 다른 언어의 애플리케이션을 고려하여 올바른 동작을 보장하고 인터페이스 구현의 어려움을 보장하는 데 있습니다. Libc에 의해. 뉘앙스를 고려하지 않은 정면 접근 방식은 기존의 많은 프로그램이 Libc와 함께 작동할 수 없다는 사실로 이어질 뿐이지만 그러한 프로젝트는 소비자에게 관심이 없을 것입니다.
• 기업 개발은 Libc를 망칠 수 있지만 이를 널리 사용하게 되므로 애플리케이션의 호환성을 보장하기 위해 해킹을 추가해야 합니다. 기업 오픈 소스 프로젝트의 후원에 따른 개발은 회사의 요구와 솔루션 쪽으로 담요를 끌어당겨 커뮤니티의 이익을 손상시킬 것입니다. 예를 들어, 다른 프로그램의 버그로 인해 발생한 문제를 식별한 경우 제어 개발에서는 버그 자체를 수정하는 것보다 Libc가 이 버그와 호환되는지 확인하는 것이 더 쉽습니다. Apple은 이러한 목적으로 BSD libc 포크를 사용하고 Google은 Fuchsia에서 musl 포크를 사용합니다. musl 개발자의 경험에 따르면 라이센싱 문제를 명확히 하기 위해 주로 변호사로부터 연락을 받았지만 지점에 쓸모없고 파괴적인 변경을 하기 전에 기술적인 세부 사항을 명확히 하기 위해 연락을 받은 적은 한 번도 없었습니다.
• libc 개발에서 단일 문화가 없고 개별 제어보다는 합의 기반 표준에 중점을 두어 애플리케이션 개발자가 특정 구현에 얽매이기보다는 표준을 사용하도록 동기를 부여합니다. 이것이 바로 musl의 작성자가 LLVM에 자신의 라이브러리를 포함하는 것과 LLVM 내에서 libc를 개발하는 것에 반대하는 이유입니다. 이 경우 libc의 독립적인 특성이 손실되고 특정 구현이 LLVM에 대한 일류 솔루션이 되기 때문입니다. LLVM 및 기타 모든 솔루션은 2급 솔루션이 됩니다.

출처 : opennet.ru