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