libc.so.6 (GLIBC_2.0)
libc.so.6 (GLIBC_2.1)
제 시스템이 glibc-2.0.7 환경이므로 glibc-2.1이 필요하다면서 설치가
되지 않는 것은 이해가 되는데, 위의 에러 메시지를 보면 glibc-2.0과
glibc-2.1을 모두 필요로 하고, 둘 다 libc.so.6이라는 이름으로 되어
있는 것을 요구하는 것 같습니다. 그게 좀 이해가 되지 않는 점이예요.
제가 틀렸다면 지적해 주시고요, 궁금한 점에 대해 설명을 부탁드립니다.
--
김승범
전부터 glibc 버전문제로 고민이 많으시군요.
glibc-2.1.1 를 쓰는 대부분의 배포본들이 이전 버전과의 바이너리 호환성을
고려하여 glibc-compat 패치를 적용하기 때문으로 알고 있습니다.
저도 김승범님 처럼 이전에는 레드햇 5.2 기반의 glibc-2.0.7 환경이었습니다만,
그 상태에서 glibc-2.1.1 final 로 업그레이드한 경험이 있습니다.
이 때 RPM으로 빌드하지 않고 타볼타입의 소스를 이용했던 관계로
RPM 패키지로 만든 바이너리를 설치할 때마다 위의 두 glibc 의존성을 묻는
귀찮은 메세지를 무시하고 --nodeps 옵션으로 설치하곤 했었죠.
glibc-2.0.7 라이브러리를 살려둔 채로 2.1.1로 업그레이드하면 심볼릭링크만
바뀐 채 이전의 바이너리 파일들이 거의 대부분 문제없이 돌아갈 겁니다.
그게 찜찜하다면 새로 glibc-2.1.1을 RPM으로 빌드하거나 바이너리로 받아
설치하는 방법을 쓰고 이 상태에서 천천히 기존 바이너리들을 새 환경에 맞게
대체해 가는 수도 있겠죠.
참, 저는 glibc-2.1.1로 업하기 전에 먼저 egcs-1.1.2로 컴파일러를 만든 후에
모든 전제조건을 충족시켜서 실행했습니다. 지금은 egcs/gcc-2.95 스넵샷
7월 18일 것을 쓰고 있는데, gcc-2.95 스넵샷으로 glibc-2.1.1을 컴파일할 경우,
6월 30일 것 이후의 것은 ./configure 실행시 gcc 컴파일러를 구버전으로
착각하는 관계로 사용하실 수 없을 겁니다. 따라서 egcs-1.1.2 내지 gcc-2.95
19990630 prerelease가 대안이 될 수 있겠죠.
기존에 만들어 놓은 소중한 환경을 "밭갈기"하기가 영 내키지 않아,
C 컴파일러부터 glibc를 거쳐 X관련 환경을 모두 빌드하면서 느낀 점은, 그래도
제대로된 배포본을 쓰는 것이 시간적으로는 더 절약될 것이라는 생각이었습니다.
물론 그 많은 패키지들을 모두 자신의 주어진 환경에서 만들어 냈다는
뿌듯함은 또다른 보상이었지만 말입니다. :)
아, 그리고 VIM-5.4만을 위해서라면 현재 상태에서 SRPM을 받아다 컴파일하는
것도 좋을 듯 합니다.
참고가 되었기를 ...
>참, 저는 glibc-2.1.1로 업하기 전에 먼저 egcs-1.1.2로 컴파일러를 만든 후에
>모든 전제조건을 충족시켜서 실행했습니다. 지금은 egcs/gcc-2.95 스넵샷
>7월 18일 것을 쓰고 있는데, gcc-2.95 스넵샷으로 glibc-2.1.1을 컴파일할 경우,
>6월 30일 것 이후의 것은 ./configure 실행시 gcc 컴파일러를 구버전으로
>착각하는 관계로 사용하실 수 없을 겁니다. 따라서 egcs-1.1.2 내지 gcc-2.95
>19990630 prerelease가 대안이 될 수 있겠죠.
그 사이 gcc-2.95가 정식으로 릴리즈되었습니다. 이걸 오늘 알았네요 :)