1

나는 나를 귀찮게하는 문제가있다. 나는 과거에 그것을 만난 것으로 생각하지만 인터넷에서 비슷한 문제에 관한 정보를 찾을 수는 없습니다.정적 라이브러리 종속성 트리에서 다이아몬드 문제입니까?

  • 는 '일반적인'도서관과의 두 개의 서로 다른 정적 libs가 : libcommon1.2.a 및 libcommon1.3.a을

    내가 가진 가정합니다.

  • libcommon1.2.a를 사용하고 새로운 정적 lib를 제공하는 '추가 공통'라이브러리입니다.
  • 최신 '공통'(libcommon1.3.a) 및 최신 '추가 공통'('공통'및 '추가 공통'이 앱에 링크되어 있음)을 사용하는 최종 앱입니다.

'common'v1.3과 v1.2 사이에 새로운 구성 요소 만 추가 된 경우 모든 것이 잘되어야합니다. 맞습니까?

'common'v1.3이 'extra-common'에서 사용하는 API를 변경 한 경우 'app-common'을 나머지 app과 연결하는 동안 누락 된 기호 문제가 발생할 수 있습니다.

'common'v1.3이 v1.2와 동일한 API를 유지하지만 일부 내부 부품을 변경하면 런타임에 오브젝트 크래시가 발생할 수 있습니까 (오브젝트의 크기가 변경되었거나 vtable 등이 변경되었을 수 있습니다).)?

Google에서 할 수있는 용어를 몇 개 보내 주시겠습니까? 어떤 경우 런타임 오류가 발생하거나 기사 링크가 생길 수 있습니까? 그러한 용어는 "도서관 의존의 다이아몬드 문제"와 같은 것입니까?

나는 무엇이든을 위해 고맙게 여길 것입니다.

+0

중복 심볼이있을 가능성이 높습니다. 컴파일하면 런타임에 문제가 없어야합니다. (당신은 dll/souce 코드에 대해 이야기하지 않는다고 가정) –

답변

3

여기서 설명하는 (가능한) 문제점은 의존성에 다이아몬드 구조가 있다는 것이 아니라 libcommon1.2a에 의존하는 라이브러리 (별도의 공통)를 사용하고 있다는 것입니다. 대신 libcommon1.3a와 다시 연결하십시오. 그게 안전하지 않은 이유를 이미 이해 한 것 같습니다.

당신이 찾고있는 용어가 ABI: application binary interface이라고 생각합니다. 호출 규칙 및 구조 레이아웃과 같이 함께 연결된 모듈간에 일치해야하는 컴파일 된 코드의 요소입니다. ABI는 API과 유사하지만 소스 코드 대신 컴파일 된 코드의 호환성과 관련이 있습니다. 두 가지는 서로 독립적입니다. ABI를 깨지 않고 API를 깨뜨릴 수 있습니다 (예 : 구조의 필드 이름 바꾸기). API를 중단하지 않고 ABI를 중단 할 수 있습니다 (예 : 데이터 유형의 크기를 변경하거나 구조).

libcommon1.3a가 libcommon1.2a와 ABI 호환되지 않는 경우 안전하게 추가 라이브러리를 사용할 수 없습니다. libcommon1.3a 헤더를 사용하여 별도의 공통 구성 요소를 다시 컴파일해야합니다. (만약 1.3a가 API와 호환이되지 않는다면, 너무 자주 변경해야 할 것입니다.)