GLIBC 업그레이드로 무엇이 잘못 될 수 있습니까?

최근에 내 그룹에서 내년 9 월부터 연구 프로젝트에 필요한 소프트웨어를 설치했습니다. glibc 2.12.1과 함께 사용할 때 소프트웨어에 알려진 충돌 버그가있는 것으로 나타났습니다. 상사는 glibc를 실행할 서버에서 glibc를 업그레이드 할 수 있는지 물었습니다. 회의적인 침묵

어느 시점에서, 나는 glibc를 엉망으로 만드는 것이 배고픈 퓨마를 엉망으로 만드는 것만 큼 좋은 아이디어라는 것을 내 두뇌에 넣었습니다. 그러나 나는이 신념의 근원을 결정할 수 없었다. 따라서이 작업을 계속하면 :

나는 멍청한 짓을하고 있습니까 (예를 들어, 문제를 해결하지 못하거나, 서버를 깨뜨 리거나 좀비 종말을 시작할 것입니까)?
무엇이 잘못 될 수 있습니까?
무엇이 잘못 될 가능성이 있습니까?
2와 3에 대한 답변을 어떻게 피할 수 있습니까?

linux glibc

— 세븐리스
소스

먼저 배포판에 버그를 수정하는 glibc 업그레이드가 있는지 확인하십시오. 배포판의 특정 glibc는 공식 glibc와 비교하여 glibc에 대한 많은 백 포트 / 버그 픽스를 포함 할 수 있지만 배포판 버전은 여전히 동일합니다.

— nos

부팅 가능한 이동식 미디어 (USB 플래시 스틱, CD, DVD)가있는 한 머신은 실제로 벽돌로되어 있지 않습니다. glibc를 다시 설치하면 복구가 가능합니다. 위험을 피하기 위해 루트가 아닌 사용자로 새 glibc를 컴파일 한 --prefix=$HOME다음이를 가리키고 LD_LIBRARY_PATH작동하는지 확인할 수 있습니다. 루트가 아닌 사용자는 아무리 엉망이 되어도 전체 시스템을 망칠 수 없습니다. 그래도 문제가 해결되지 않으면 변경 하여 연구 프로젝트의 요구 사항으로 --prefix=/usr/local/bleeding-edge-glibc문서화LD_LIBRARY_PATH=/usr/local/bleeding-edge-glibc/lib

— Alan Curry

배포판을 업그레이드 할 수 없습니까? 그리고 어떤 glibc버그가 무엇인지, 어떤 종류의 소프트웨어를 사용하고 있는지 알려 주어야합니다 . 소스 코드가 있다고 가정하고 소프트웨어를 패치하거나 시스템을 우회하도록 시스템을 구성 할 수 있습니다.

가능할 때마다 새 프로젝트에 이전 서버 소프트웨어를 사용하지 마십시오.

— Michael Hampton

보다 신선한 libc를 컴파일하는 것이 종종 가능하며, 한 소프트웨어는 다른 사람에게 다른 라이브러리를 사용하게합니다.

libc 버전 사이의 가장 큰 어려움은 스레드 로컬 스토리지 IIRC입니다. 이 이정표를 통과하면 모든 베팅이 해제됩니다.

모든 것을 말했지만-단순히 배포판을 현대적인 것으로 업그레이드하는 것이 좋습니다. 단편 업그레이드를하면 몇 달 동안 꼬리를 쫓는 고통이 생길 수 있습니다.

— 톰 뉴턴
소스

호환성 표 를 참조하여 이진 호환 버전을 확인할 수 있습니다 .

일반적으로 glibc를 최신 버전으로 업그레이드하는 것은 문제가되지 않지만 배포에 사용 된 것과 동일한 구성 플래그로 빌드해야합니다 (적절한 SRPM 패키지의 사양 파일 참조).

— linuxbuild
소스