저는 현재 크로스 플랫폼 공유 라이브러리를 개발 중이며 *nix에서 작동하는 올바른 방법에 대해 약간 혼란스럽습니다. 내 버전 계획은 꽤 표준적이며, 주요 릴리스는 인터페이스를 중단하고, 부 릴리스는 인터페이스를 추가하지만 여전히 이전 버전과 호환되며, 패치 번호는 인터페이스를 포함하지 않는 버그 수정/개선 사항입니다. 이는 마이너가 SO 버전을 높여야 함을 의미합니다.
따라서 라이브러리의 파일명은 libNAME.so.X.Y.Z라이브러리 버전 X.Y.Z이고 설치명은 libNAME.so.X.Y. 내 문제는 부 버전을 업데이트할 때 기존 링크된 실행 파일이 새 라이브러리를 사용하기를 원하지만(X.0.0과 역호환되기 때문에) 실행 파일이 이전 부 버전에 링크된다는 것입니다 libNAME.so.X.Y. 그렇다면 이는 현재 버전 아래의 모든 부 버전에 대한 심볼릭 링크 목록을 유지하고 공유 라이브러리를 업그레이드할 때마다 새 라이브러리를 가리키도록 모두 업데이트해야 함을 의미합니까?
답변1
라이브러리를 사용하는 프로그램은 libNAME.so최신 버전, libNAME.so.X최신 주요 버전 X, libNAME.so.X.Y특정 부 버전을 원하는 경우 연결해야 합니다.
추가 링크만 제공하는 libNAME.so경우libNAME.so.X 그리고 libNAME.so.X.Y모두 libNAME.so.X.Y.Z최신 버전을 사용하며 언제든지 이 링크를 업데이트할 수 있습니다.
설치하려는 버전이 마이너 버전으로 업그레이드되었다고 가정하면 링크는 다음과 같습니다(Y-1은 Y 이전의 숫자이고 z는 XY-1 시리즈의 최신 패치 수준이라고 가정).
libNAME.so -> libNAME.so.X.Y-1.z
libNAME.so.X -> libNAME.so.X.Y-1.z
libNAME.so.X.Y-1 -> libNAME.so.X.Y-1.z
업데이트를 설치한 후(Z는 0 또는 1일 수 있음):
libNAME.so -> libNAME.so.X.Y.Z
libNAME.so.X -> libNAME.so.X.Y.Z
libNAME.so.X.Y-1 -> libNAME.so.X.Y-1.z
libNAME.so.X.Y -> libNAME.so.X.Y.Z
XY-1을 사용하도록 명시적으로 링크된 모든 프로그램은 여전히 XY-1.z 파일을 찾습니다.
이 구성표에 따르면 표시된 링크를 제외한 이전 링크를 업데이트할 필요가 없으며 주요, 부 또는 패치 번호 변경 사항(1, 2, resp 3 링크)에서 어떤 링크가 있는지 확인할 수 있습니다.
과거에는 시스템에 이러한 "중간" 링크가 있는 오래된 저장소를 갖는 것이 더 일반적이었습니다. 그러나 패키지 관리는 종종 이전 버전을 제거합니다.
^ 저는 이전 버전을 사용하라는 명시적인 요청을 받지 않은 경우 링크를 통해 최신 버전을 얻을 수 있는 이런 방식을 항상 좋아했습니다. Microsoft MFC 컨퍼런스(1994)에서 DLL은 다음과 같이 소개되었습니다.해결책공유 라이브러리의 경우, 나는 그러한 입증된 체계 없이 이전 버전에 액세스하는 문제를 연사에게 지적했습니다. "DLL 지옥"이라는 용어는 그 당시에도 아직 만들어지지 않았습니다.