저는 C++0x 표준을 대상으로 C++로 작성된 오래된 코드 베이스의 새로운 관리자입니다. 코드에는 여러 gcc 및 g++ 종속성이 포함되어 있습니다. CentOS 7 EOL 이후 프로그램의 종속성을 패치하는 것이 걱정됩니다. 물론 아직 4년은 남았지만 계획을 세우는 게 낫지 않을까…
이 코드베이스의 많은 문제 중 하나는 코드가 다음에 의존한다는 것입니다.GNU 경로. 라이브러리는 2006년 이후로 업스트림으로 유지되지 않았으며 이제 새 소프트웨어는 Boost 코루틴 또는 유사한 동작을 사용하여 동등한 동작을 달성하거나 pthread를 사용해야 합니다.
나는 Pth 또는 Pth 자체의 사용이 버전 2.17(CentOS 7에서는 잘 작동함) 및 2.27(Ubuntu 18.04에서는 glibc 중단)에 도입된 버그나 호환되지 않는 변경 사항에 달려 있다고 100% 확신합니다. 우리 소프트웨어). 전체 소스 코드와 디버깅 기호가 있더라도 이 문제는 디버깅에 매우 해롭습니다. Pth의 운영 모델이 지속적으로 스택을 손상시켜 프로그램이 어떻게 특정 오류 모드에 진입했는지 파악하기 어렵게 만들기 때문입니다.
문제를 glibc 버전으로 분리하고 glibc 2.28을 사용하여 CentOS 8에서 시도해 보았습니다. 나에게 이것은 회귀가 아니라 의도적인 변경처럼 보이지만 이전 버전과의 호환성을 깨뜨립니다.
최근에 관찰된 glibc 충돌은 여기서 중점을 두지 않습니다. CentOS 7보다 EOL 날짜가 더 길고 CentOS 8 또는 Ubuntu 20.04에서 glibc 2.17을 지원할 계획인 리포지토리가 있는지 궁금합니다.
물론 glibc 2.17을 컴파일하고 이를 바이너리에 정적으로 연결할 수 있지만 이는 더 이상 해당 버전의 glibc에 대한 보안 업데이트를 받을 수 없음을 의미합니다. 소프트웨어는 공용 인터넷에서 액세스할 수 있는 포트에서 직접 수신 대기하므로 이 아이디어는 전혀 마음에 들지 않습니다.
결국 손상을 일으킨 정확한 버전의 glibc를 찾기 위해 git을 통해 양분할 수도 있지만, 그래도 부담은 여전히 남아 있습니다.내 거내가 선택한 glibc 버전에 대한 보안 패치를 유지관리합니다. 제가 엔터프라이즈 배포판을 좋아하는 이유 중 하나는 수년간 완전히 ABI 및 API를 준수하는 보안 업데이트를 받을 수 있기 때문에 편리할 때 애플리케이션 소프트웨어 포워드 포팅을 천천히 처리할 수 있다는 것입니다. 이상해 보일 수도 있지만 이 일정을 2024년 6월(CentOS 7 보안 업데이트 종료) 이후로 연장하고 싶습니다.
이전 버전이지만 패치가 적용된 glibc를 계속 사용하려면 어떻게 해야 합니까? 아니면 좋은 옵션이 없다면 지금부터 2024년 6월 사이의 시간을 이용해 근본적인 문제를 해결하여 업그레이드하는 것이 더 나을까요?