gcc 4.7내 사용자 공간(패키지)이 (Debian Wheezy) 로 libc6 2.13컴파일 되었다고 가정해 보겠습니다 .
gcc 6.3다른 개발 환경 ( 예: Debian Stretch) 에서 Linux 커널을 컴파일할 수 있나요 libc6 2.24?
패키지와 달리 커널은 동적 라이브러리와 연결되어 있지 않다는 것을 알고 있습니다. 따라서 이론적으로는 그것이 컴파일된 gcc것과 libc컴파일된 것 사이에 차이가 없어야 합니다 .
이게 진짜야? 내가 이 일을 하면 문제가 생길까? gcc버전이 달라서 호환성이 떨어지는 건 아닐까요 ?
반면에 최신 버전에는 gcc몇 가지 흥미로운 기능과 더 나은 보안 기능이 있습니다. 그렇다면 커널을 최신 버전으로 컴파일해야 할까요 gcc?
답변1
지적하신 대로 사용 중인 C 라이브러리는 C 라이브러리를 사용하지 않는 커널에 아무런 영향을 미치지 않습니다. (빌드 과정에서 커널이 사용하는 도구를 빌드하는 데 사용되기 때문에 간접적인 효과는 있지만 최종 결과에 영향을 미칠 가능성은 거의 없습니다.)
커널은 문서에 따라 다양한 컴파일러 버전으로 구축될 수 있으며 GCC 3.2 이상만 필요합니다. 또한 커널이 최신 버전의 GCC를 공식적으로 지원하는 데 시간이 걸릴 수 있으며 릴리스 커널에서 이를 사용하는 데는 더 오랜 시간이 걸릴 수 있습니다. 예를 들어 Debian Linux 커널 패키지는 GCC 6을 사용하며 올바른 컴파일러 버전을 제공하는 전용 패키지도 있습니다(linux-compiler-gcc-6-x86및 amd64) i386. 커널에 사용되는 컴파일러와 사용자 공간에 사용되는 컴파일러 사이에는 연결이 없습니다(또한 모든 사용자 공간에 대해 반드시 동일한 컴파일러일 필요는 없습니다. GCC 3 또는 심지어 2로 빌드된 이전 프로그램은 최신 시스템에서 계속 실행됩니다) .
최신 컴파일러 버전은 더 많은 보안 기능을 제공하지만 GCC 6은 커널에서 사용되는 대부분의(전부는 아니지만) 보안 기능에 충분합니다.
답변2
사용자 공간 패키지와 다른 툴체인을 사용하여 커널을 컴파일할 수 있습니까? 예.
커널의 핵심 원칙 중 하나는 사용자 공간과 커널을 분리하는 것입니다. 둘 사이에는 시스템 호출 인터페이스라는 잘 정의된 인터페이스가 있습니다. 사용자 공간 프로그램이 이를 존중하는 한 커널과 동일한 툴체인으로 컴파일되는지 여부는 중요하지 않습니다. 실제로 많은 프로그램이 C나 어셈블리 언어로 작성되지 않고 JVM에서 실행되는 Java 프로그램과 같이 완전히 다른 컴파일러와 런타임 환경을 사용합니다.