내 (C++, 크로스 플랫폼) 앱은 Boost 라이브러리 (버전 1.x)를 많이 사용하고 있으며 자체적으로 Boost을 사용하는 제 3 자 (공급 업체)의 SDK (소스 없음) 1.y).동일한 (부스트) DLL의 여러 버전을 동일한 프로세스에서 공존 할 수 있습니까?
그래서 우리는 우리 자신의 버전 Boost DLL에 대해 동적으로 링크합니다. CRT는 동일합니다. 결과적으로, 런타임에 내 애플은 Boost 1.x & 1.y의 DLL을 모두로드해야합니다.
잠재적 인 문제는 무엇입니까 & gotchas가 연관되어 있습니까?
공급 업체의 SDK를 변경할 수는 없지만 앱을 변경할 수 있습니다. 어쩌면 나는 내 Boost 1.x에 대해 정적으로 링크해야합니까?
추 신 : Boost의 DLL 이름은 해당 버전을 포함하므로 이름 충돌이 없어 식별 할 수 있습니다. 평범한 DLL이 아닙니다.
foo 함수를 작성하여 F.dll에서 내보내고 다른 함수 foo을 G.dll에서 내 보낸 경우 문제가 발생합니까?
AF.exe가 링크되면 링커에게 다음과 같이 알려줍니다. F.dll에서 함수 foo의 주소를로드하는 코드를 그 안에 넣습니다. 이제 BG.dll은 G.dll에서 foo 주소를 검색하기 위해 연결됩니다. 나는 아직도 아무 문제도 보지 않는다.
AFFF를 앱으로, BG.dll을 공급 업체의 앱으로, F.dll을 부스트 버전으로, G.dll을 공급 업체의 부스트 버전으로 바꿉니다.
결론 : dll 이름이 다른 경우 문제가 없습니다.
다른 버전의 DLL을 사용하는 한 아무런 문제가 없어야합니다. 적어도 Windows에서는 그렇지 않습니다.
SDK가 내부적으로 부스트를 사용하는 경우에도 마찬가지입니다. SDK가 인터페이스에서 boost 구문을 사용하는 경우 (예 : boost :: optional을 반환하는 함수가있는 경우) 여러 버전에서 문제가 발생할 수 있습니다. 버전 간 변경 사항에 따라 문제가 해결 될 수도 있지만 위험 할 수 있습니다. 나는 그럴만한 좋은 해결책을 모른다. 부스트 헤더 파일이 포함 된 SDK 헤더 파일을 포함하는 경우에도 마찬가지입니다.
큰 문제입니다. DLL 지옥에 대한 검색을 수행합니다.
기본적으로 DLL (또는 Linux의 공유 라이브러리)은로드되지만로드시 모든 이름이 해석되는 것은 아닙니다. 게으른 평가가 수행되므로 처음 사용시 이름이 평가됩니다. 문제는 두 dll에 같은 이름이 있으면 이름이 해석되는 위치는 DLL이 검색되는 순서 (로드 순서에 따라 다름)에 달려 있다는 것입니다.
정적으로 링크하면 메서드 호출시 문제가 발생하지 않으므로 컴파일 타임에 문제가 해결되고 타사는 DLL에서 런타임에 해결됩니다. 그러나 버전 1 향상에 의해 만들어진 구조는 어떨까요? 그런 다음이를 타사 라이브러리에 전달하면 버전 -x 부스트로 전달합니다. 구조가 같은 방법으로 배치되어 있습니까?
이것은 매우 까다로운 영역이며 문제가 발생하면 버그를 제거하기가 매우 어려워집니다. 그래서 같은 버전을 사용해보십시오.