2012-02-06 2 views
5

최근 GCC (4.3.3)를 사용하는 C++ 코드베이스가 있지만 GCC 3.2를 사용하여 빌드 된 이전 라이브러리와 링크해야합니다. 삼. 사용할 수있는 라이브러리의 최신 버전이 없으며, 라이브러리가 없어도 사용할 수 없습니다. 다시 빌드 할 수 없도록 닫힌 소스입니다.레거시 라이브러리에 대한 빌드 C++ ABI를 혼합

이것은 GCC 4.3.3과 3.2.3 사이에 ABI 비 호환성이 있으므로 문제를 일으키는 것 같습니다. 그래서이 문제를 해결하기위한 내 옵션이 무엇인지 확인하려고합니다.

몇 가지 추가 정보 :

    내가 올바른 ABI 버전을 얻을 -fabi 버전 = 1 내 코드베이스에서 모든 것을 다시 할 수 있지만, 내가 된 libstdc에서 몇 가지 새로운 기능에 의존 오전
  • ++ 버전 6
  • 코드베이스 외부의 모든 C++ 라이브러리 종속성은 오픈 소스이므로이 라이브러리를 제외하고 필요에 따라 다시 빌드 할 수 있습니다.
  • 재구성 할 수 없거나 다시 작성할 수없는 많은 C 라이브러리 종속성.

    • 이 -fabi 버전 = 1 및 링크 모든 C++ 코드와 종속 라이브러리를 재 구축 :
    • 오래된 도서관은 5 개 기능

    내가 지금까지 시도 일부 된 libstdC++ 버전에 의존하는 것 같다 libstdC++ 버전 6에 대해. 이것은 C++ 표준 라이브러리 심볼에 대해 정의되지 않은 심볼 오류가 몇 개 발생하여 실패합니다.

  • 위와 같지만 libstdC++ 5의 공유 라이브러리에 추가로 링크되어있어 링커 문제는 해결되지만 런타임시 두 버전이 레거시 라이브러리 내부에서 혼합되어 충돌이 발생하는 것으로 보입니다.

이 글은 http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html입니다. 이는 라이브러리 간의 다양한 종속성을 충족시키기 위해 응용 프로그램에 C++ ABI 버전을 혼합 할 수 있음을 나타냅니다. 내가 뭔가를 놓치지 않으면 여기서 잘 작동하지 않는 것 같습니다.

아이디어가 있으십니까? 에

+0

링커 옵션'-Bsymbolic'과'--exclude-libs'는 이전 libstdC++를 정적으로 공유 라이브러리에 링크 할 때 도움이 될 것입니다. –

답변

3

좋아, 당신의 해결 방법은 다음과 같습니다

  • 이전 C++ 라이브러리에 "C"인터페이스를 쓰기 때문에이 작동 3.2.3로 컴파일합니다.
  • 이제 새 컴파일러에서 C 인터페이스를 사용할 수 있습니다.

C 라이브러리에서 C++ "래퍼"코드를 작성하여 C++로 사용할 수 있지만이 코드는 새 컴파일러에서 빌드됩니다.

+1

물론 이것은 묶음 코드를 추가하는 단점이 있지만 모든 C 컴파일러/버전 쌍으로 작업 할 수 있다는 장점이 있습니다. – kibibu

+0

그것은 합리적인 접근법처럼 보입니다. 공유 라이브러리를 만들면 이전의 libstdC++ 공유 라이브러리에도 여전히 의존성이 생깁니다. 동일한 문제가 발생하지 않습니까? 아니면 이전 버전에서 정적으로 링크해야합니까? –

+0

더 많은 파기를 한 후에, libstdC++를 이전 GCC에서이 공유 라이브러리로 정적으로 링크하는 것이 옳은 것처럼 보입니다.그러나 라이브러리 경계를 넘어 공유되는 기호를 사용하면 이전과 동일한 문제가 발생할 가능성이 있기 때문에 그 점을 연결하는 것만으로는 충분하지 않습니다. 내 생각에 당신은 응용 프로그램 내부에서 dlopen을 수행하고 RTLD_NOW | RTLD_DEEPBIND | RTLD_LOCAL. –

관련 문제