GLIBC의 호환성 문제는 어떻게 극복해야 하나?

Written by Keith
on 

블로그 조회수가 이 글 때문에 많이 늘어났다. 호환성 문제 때문에 겪었던 일에 대한 생각을 적은 것인데 별 도움이 안될 듯 하여, 급한 답이 필요한 사람들을 위한 답으로 내용을 수정한다.

glibc는 gnu c library를 의미한다. 이게 왜 중요하냐 하면 linux 위에서 돌아가는 거의 대부분의 소프트웨어가 여기에 기반하고 있기 때문이다.

사실상 glibc의 버전이 몇 이냐에 따라서 해당 linux package의 전체가 결정된다고 볼 수도 있다. glibc 때문에 고충을 겪는 경우는 딱 하나다. 내 OS의 glibc 버전의 내가 실행하려는 바이너리를 빌드할 때 사용되었던 glibc에 비해 낮은 버전인 경우다. glibc 자체가 하위 호환성을 중요시하기 때문에 내가 높은 버전의 glibc를 가지고 있다면 구 버전의 glibc로 빌드된 바이너리들을 실행하는 데는 아무런 문제가 없다.

대개 라이센스 비용이 비싼 linux 툴들을 사용하는 곳에서 RHEL 또는 이와 유사한 linux distro를 사용한다. 대개 이들은 안정성(?) 때문에 구형의 라이브러리를 사용하는 경향이 있다. 말이 안정성이지 새로 나온 linux에서 테스트해보기 싫었거나 linux 자체가 워낙 다양한 distro가 있어서 모두 다 테스트해볼 수 없었기에 그저 과거의 특정시점에 나온 distro에 고정하려고 한 것이지 싶다.

안정성이 확보되어있다 뭐 그런 이유 때문인지는 모르지만, 작년인가 RHEL 6의 지원이 중단되었다. 아마도 7도 곧 중단되지 싶다. 왜? 나온지가 20년이 넘었다고 한다. 너무 기가막히지 않은가? 핸드폰도 1-2년에 한번씩 새것으로 바꾸는 시대에 20년이 넘은 OS에서 중요한 일을 하고 있다니.

어쨌든 호환성 문제를 해결하기 위한 답은 아주 간단하다.

내가 사용하는 linux 배포판의 버전을 올리거나 docker를 이용하면 된다. glibc의 so (shared object)만 복사해오면 되는 것 아니냐 할 수 있는데, 만일 그것이 동일한 환경에서 새로 빌드된 glibc면 다행이지만 안 그럴 확률이 훨씬 높다. glibc는 하위호환이 된다. 따라서 최근 버전의 glibc는 과거 버전으로 빌드된 모든 바이너리를 실행할 수 있다. 판수를 올려주면 쉽게 해결된다.

아니면 docker를 사용해서 높은 판수의 컨테이너를 불러다가 그 안에서 실행하면 된다. 그러나 대개 구형 linux들은 docker도 실행할 수 없을 확률이 높다.

그 누군가가 내가 빌드하는 환경에 비해 구버전의 리눅스를 사용한다는 말이다. 해답은 그쪽에서 판수를 올리라고 하거나 아니면 내가 판수를 내리는 것이다. docker로 낮은 판수의 컨테이너를 불러다가 빌드하면 된다. 호환성은 좋아지는 반면 빌드시에 발생하는 문제도 모두 해결해야 되고 (컴파일러 최적화/CPU 명령어 셋이 줄어서) 실행 속도가 떨어지게 된다.

그 외에 특정 소프트웨어들은 배포판 별로 특화된 라이브러리들을 필요로 하는 경우가 있다. 가장 쉬운 해결 방법은

사실 docker가 없었다면 문제의 해결방법은 좀 복잡해진다. 사용하지 않는 기계에 옛날 OS 배포판을 구해다 설치해야 하고, 빌드 용도 말고는 아무 짝에도 쓸모 없게 된 그 머신을 별도로 관리해야줘야 하니까 말이다. 더 황당한 것은 구형 리눅스를 새 머신에 설치하면 여러가지 드라이버 문제 때문에 설치 조차 안되는 경우도 허다하다. 지금은 docker 하나면 모든 문제가 아주 쉽게 풀린다. 다시금 docker를 개발한 이들에게 고마움을 표해야 하는 것 아닐까 한다.

이 정도면 대충 급한 답은 될 수 있을 것 같다.