현재 버전의 Windows에서 작동하는 실행 파일을 빌드하는 경우 해당 실행 파일은 아마도 최신 버전의 Windows에서 수년 동안 작동할 것입니다. Microsoft는 이를 보장하기 위해 매우 열심히 노력하고 있습니다.
Linux에서는 사용 중인 소프트웨어에 대한 소스 코드가 있을 것이라는 기대가 있으므로 소스 호환성을 유지하는 한 바이너리 호환성을 깨는 것은 괜찮습니다. 이로 인해 배포판은 이전 라이브러리 버전을 단계적으로 중단하고 이전에 작동하던 기능을 주기적으로 중단하게 됩니다.
Linux를 게임 플랫폼으로 사용하는 사람에게는 게임이 바이너리 형식으로만 배포되는 경향이 있기 때문에 이것이 문제가 됩니다. Linux 포트가 고장나면 보기에 좋지 않지만 모든 사람이 포트를 업데이트할 것을 기대하는 것보다 일반적으로 이 문제를 해결하려고 시도하는 것이 더 생산적이라고 생각합니다.
릴리스 n에서 작동하는 바이너리가 릴리스 n+1에서도 작동해야 하는 것과 같이 반드시 모든 이전 버전을 유지하는 것은 아니지만 적어도 이전 소네임을 유지하여 바이너리 호환성을 유지하려는 배포판이 있습니까?
내가 찾을 수 있는 가장 가까운 것은 Steam을 통해 배포되는 프로그램에서만 사용할 수 있는 바이너리 호환성 레이어인 Valve의 "Steam Runtime"입니다.
답변1
기본적으로 이는 다음과 같이 요약됩니다.바이너리 호환성을 유지하고 새로운 기능을 도입할 수 없습니다., 이러한 것들은 대부분의 측면에서 서로 직접적으로 반대되기 때문입니다. 주요 새로운 기능을 소개한다면 결국~해야 한다ABI를 변경합니다(보통 API 변경 직후). 이제 버전이 지정된 기호(예: Glibc의 경우)를 가질 수 있지만 이로 인해 라이브러리 크기가 커지고(바이너리를 메모리에 로드하는 동안 성능 저하가 발생할 수도 있음) 개발자는 일반적으로 이를 유지하고 싶어하지 않습니다. 라이브러리(레거시 코드에는 아무도 수정에 관심이 없는 버그가 포함되어 있습니다).
배포 측면에서 이 문제를 해결하는 일반적인 방법은 두 가지입니다.
버전을 변경하지 마십시오. 이는 RedHat 및 SUSE와 같은 엔터프라이즈급 배포판뿐만 아니라 일부 다른 배포판(Debian, Slackware, Ubunty LTS 및 해당 복제본)에서도 일반적입니다.
다양한 버전의 라이브러리를 동시에 설치할 수 있습니다.
응용 프로그램 배포자에서는 Windows에서와 동일한 방식으로 처리됩니다. 즉, 필요한 모든 것을 배포 패키지에 넣습니다. 예, 이것은 Windows에서 자주 수행되는 방식입니다. 이는 또한 일반적인 Windows 시스템이 일반적으로 동일한 기능을 갖춘 Linux보다 몇 배 더 높은 디스크 공간 요구 사항을 갖는 이유 중 하나입니다. 어딘가에 자신의 사본이 있습니다. 이를 자체 GTK/Qt 스택과 함께 제공되는 모든 GTK/Qt 애플리케이션으로 생각할 수 있습니다. 몇 가지 장점이 있을 수 있지만 단점도 많습니다. 예를 들어 보안 관점에서 볼 때 Technicolor TM 에서는 악몽입니다 . 바이너리가 정적으로 링크되어 있으면 FullHD에서도 마찬가지입니다.