이전 libc 버전에 대해 빌드 및 바인딩
libc가 필요한 코드에 종속성이 있습니다. cargo build --releaseUbuntu 20.04 (glibc 2.31)에서 빌드 ( )하면 결과 실행 파일이 CentOS 7 (glibc 2.17)에서 실행되지 않습니다. GLIBC 2.18이 필요하다는 오류가 발생합니다.
CentOS 7에서 동일한 코드를 빌드하면 결과 실행 파일이 CentOS 7 및 Ubuntu 20.04에서 실행됩니다.
Ubuntu 20.04에서도이 버전을 빌드하는 데 필요한 GLIBC 버전을 제어하는 방법이 있습니까?
답변
프로젝트가 네이티브 라이브러리에 의존하지 않는 경우 가장 쉬운 방법은 x86_64-unknown-linux-musl타겟 을 사용하는 것입니다.
이 대상 은 시스템의 libc에 대해 동적으로 링크하는 대신 MUSL Libc 에 대해 정적으로 링크 합니다. 결과적으로 광범위한 시스템에서 실행되어야하는 완전히 정적 바이너리를 생성합니다.
이 대상을 설치하려면 :
rustup target add x86_64-unknown-linux-musl
이 타겟을 사용하여 프로젝트를 빌드하려면 :
cargo build --target x86_64-unknown-linux-musl
자세한 내용 은 에디션 가이드 를 참조하세요.
녹이 아닌 라이브러리를 사용하는 경우 동적으로 연결되어 시스템 libc에 종속 될 수 있기 때문에 더 어려워집니다. 이 경우 외부 라이브러리를 정적으로 연결하거나 (가능하고 사용중인 라이브러리가 MUSL libc와 함께 작동한다고 가정) 대상으로 지정하려는 각 플랫폼에 대해 다른 빌드를 만들어야합니다.
각 플랫폼에 대해 서로 다른 빌드를 만들어야하는 경우 Docker 컨테이너가이를 달성하는 가장 쉬운 방법입니다.
일반적으로 해당 OS에서 특정 OS 용 바이너리를 빌드하거나 최소한 지원하려는 가장 오래된 OS에서 빌드해야합니다.
glibc는 새로운 기능에 대한 지원을 추가하면서 이전 프로그램의 동작을 보존하기 위해 기호 버전 관리를 사용합니다. 예를 들어 최신 버전은 pthread_mutex_lock잠금 제거를 지원하지만 이전 버전 은 지원하지 않을 수 있습니다. libc에 링크 할 때 버전이 명시 적으로 지정되지 않은 경우 기호의 기본 버전에 링크하기 때문에이 오류가 표시되며, 적어도 한 가지 경우 링크 된 버전은 glibc 2.18에서 가져온 것입니다. 이를 변경하려면 libstd (및 libc 크레이트를 사용하는 경우)를 사용자 지정 변경 사항으로 다시 컴파일하여 이전 버전의 기호를 선택해야합니다.
유일한 종속성이 glibc 인 경우 CentOS 7에서 컴파일하는 것으로 충분할 수 있습니다. 그러나 OpenSSL과 같은 다른 라이브러리에 의존하는 경우 SONAME이 다르기 때문에 OS 버전간에 호환되지 않으며 방법이 없습니다. 그 주위. 그래서 일반적으로 OS마다 다른 바이너리를 빌드하려는 이유입니다.
시도해보십시오 cross.
전 세계적으로 설치하십시오.
cargo install cross
그런 다음이를 사용하여 프로젝트를 빌드하십시오.
cross build --target x86_64-unknown-linux-gnu --release
cross동일한 인수를 사용 cargo하지만 명시 적으로 대상을 지정해야합니다. 또한 빌드 디렉토리는 항상입니다 target/{TARGET}/(debug|release).target/(debug|release)
cross다른 대상 아키텍처에 대해 미리 빌드 된 도커 이미지를 사용하지만 호스트 아키텍처에 대해 "크로스 컴파일"하는 것을 막는 것은 없습니다. 이러한 도커 이미지의 glibc 버전은 충분히 보수적이어야합니다. 그렇지 않은 경우 언제든지 cross사용자 지정 이미지를 사용 하도록 구성 할 수 있습니다 .