나는 최근 고도로 숙련된 소프트웨어 엔지니어인 친구와 이야기를 나누고 있었는데 그는 나에게 libc가 glibc보다 훨씬 낫다는 사실을 설명하는 몇 가지 기사를 보여주었습니다.
대신 libc를 사용할 수 있는지, 이 경로로 가면 어떤 문제에 직면하게 되는지 궁금합니다.
답변1
맥락: 위의 설명에서 가정하면 BSDish는 libcBSDish를 의미합니다.
나는 그것이 연구되었지만 libc주어진 커널에 매우 묶여 있는 경향이 있다고 생각합니다( glibc추상화 계층이 있는데, 이는 다소 이식 가능하지만 추상화 계층으로 인해 발생하는 일반적인 문제로 이어집니다). 그리고 libcLinux 커널로 BSD를 만듭니다. 거의 완전한 재작성이 필요했습니다. 주요 시스템 서비스는 두 시스템 간에 크게 다릅니다(예: BSD는 libc소켓 쌍을 사용하므로 BSD는 파이프/FIFO가 없다고 가정합니다. 반대로 Linux는 파이프 호환 소켓 쌍을 지원하지 않습니다).
다른 방향으로 가는 것(데비안은 FreeBSD 커널 위에 실험적인 Linux 사용자 공간을 가지고 있다고 생각합니다)은 이식성 계층 덕분에 가능합니다 glibc.
답변2
답변3
많은 소프트웨어가 glibc자체나 glibc매크로 또는 glibc스타일에만 의존하므로 빌드가 실패합니다. 내부에서 무슨 일이 일어나고 있는지 알면 glibc모든 소프트웨어를 쉽게 고칠 수 있습니다 . 예를 들어 여기서 볼 수 있습니다리눅스 헤더 파일을 위한 musl. 헤더는 아직 완성되지 않았지만 커밋을 확인하고 작업이 어떻게 보이는지 확인할 수 있습니다.
glibc모든 개발자는 기본 시스템을 사용하여 소프트웨어를 테스트합니다. 모든 라이브 소프트웨어 개발을 수정하고 libc올바른 솔루션(예: 끌어오기 요청)을 사용하여 다른 소프트웨어와 호환 되도록 만드는 것은 불가능합니다 . 따라서 이와 같은 범용 시스템은 gentoo무한한 고통 없이 대체 libc를 사용하여 구축할 수 없습니다.
임베디드 개발자(예: openwrt)는 소프트웨어 버전을 수정하고 이를 해결하기 위해 많은 작업을 수행하고 있습니다. 따라서 임베디드 시스템(예: openwrt)은 다음과 같은 기능만 제공할 수 있습니다.원천musl또는 와 같은 빌드에 대체 libcs를 사용할 수 있습니다 uclibc.
other로 대체하는 glibc고통스럽지 않고 올바른 유일한 방법 은 other를 사용하여 모든 동작을 시뮬레이션하는 특수 래퍼를 libc구현하는 것입니다 . 오늘날에는 그러한 프로젝트가 없습니다.glibclibc