clang ++ -stdlib = libc ++와 함께 libstdc ++ 컴파일 된 라이브러리 사용

clang ++ -stdlib = libc ++와 함께 libstdc ++ 컴파일 된 라이브러리 사용

---

저는 Mac OS X (10.8.2)에서 C ++로 작업 중이며 최근에 libc ++ stdlib를 사용하는 clang ++ 컴파일러를 통해 사용할 수있는 C ++ 11 기능을 사용할 필요성을 생각해 냈습니다. 그러나 libstdc ++ (MacPorts에서 제공)에 대해 컴파일되고 연결된 레거시 라이브러리도 사용해야합니다.

이렇게하면 예를 들어를 사용하는 레거시 라이브러리의 헤더가 구현 대신 (즉,의 libc ++ 구현 ) std::string에 대해 해결되어야 했기 때문에 링크 오류가 발생했습니다 .std::__1::basic_stringstd::stringstd::basic_string

개발중인 두 라이브러리를 혼합하는 방법이 있습니까 (예 : 일부 전 처리기 플래그 사용)?

---

지금보고있는 것은 ABI 버전 관리를 위해 인라인 네임 스페이스 를 사용하는 것입니다 .

의미 :

libstdc ++ std::string는 libc ++와 다른 데이터 구조 std::string입니다. 전자는 참조 횟수 설계이지만 후자는 그렇지 않습니다. API와 호환되지만 ABI와는 호환되지 않습니다. 즉 std::string, libstdc ++를 사용하여를 생성 한 다음 libc ++에 연결된 다른 코드로 전달하면 수신 코드가 libc ++가 있다고 생각합니다 std::string. 즉, 수신자는 참조 횟수를 늘리거나 줄여야한다는 단서가 없습니다.

인라인 네임 스페이스가 없으면 결과는 런타임 오류입니다. 당신이 바랄 수있는 최선은 충돌입니다. 인라인 네임 스페이스를 사용하면이 런타임 오류가 링크 시간 오류로 변환됩니다.

프로그래머에게 libstdc ++ std::string와 libc ++ std::string는 같은 유형으로 보입니다. 그러나 링커에게는 완전히 다른 유형처럼 보입니다 (단서는 std::__1네임 스페이스입니다). 그리고 링커의 견해가 정확합니다. 그들은 수 있습니다 완전히 다른 종류.

그래서 예, 당신은 물건을 연결하기 위해 일부 전 처리기 플래그를 조작 할 수 있습니다. 그러나 결과적으로 발생하는 런타임 버그를 디버깅하는 데 시간이 많이 걸립니다.

당신이 원하는 것을 할 수있는 유일한 방법은이 dylibs 사이의 인터페이스를 포함하지 만드는 것입니다 std::같은 유형 string. 예를 들어 char대신 배열을 전달할 수 있습니다. libstdc ++ 링크 코드에서 libc ++ 링크 코드로 또는 그 반대로 메모리 소유권을 전송할 수도 있습니다 (둘 다 동일한 malloc 풀로 삭제됩니다).

참고 URL : https://stackoverflow.com/questions/12542971/using-libstdc-compiled-libraries-with-clang-stdlib-libc