은 라이브러리 (.so를) 동적으로 다른 컴파일러로 만든 다른 라이브러리를로드 할 수

Question

요약 :

나는 하나의 라이브러리는 동적으로 또 다른로드와 컴파일러의 차이가 인 경우 내가 궁금하네요에 문제가 오전 근본 원인.

문제점 세부 사항 : libgbm.so에

내 응용 프로그램 링크는 동적으로 libpvrGBMWSEGL.so를로드 한 후 gbm_backend 기능을 요청합니다.

#libgbm.so 

module = dlopen("/usr/lib/libpvrGBMWSEGL.so", RTLD_NOW | RTLD_GLOBAL) 
dlsym(module, entrypoint) 

제공된 기호를 사용하려고하면 세그먼트 오류가 발생합니다.

분석 : libpvrGBMWSEGL.so는 고유 이진 BLOB으로 제공된다

.

: 빠른 분석은 리나 GCC와 함께 동적으로 6.4.0

> strings libgbm.so | grep GCC 
GCC: (Buildroot 2017.11-git-00884-g7af8140-dirty) 6.4.0 

질문 Buildroot GCC로 구축했다 호출 5.3-2016.02

> strings libpvrGBMWSEGL.so | grep GCC 
GCC: (Linaro GCC 5.3-2016.02) 5.3.1 20160113 

한편 도서관 libgbm를 만들 것을 보여줍니다

이 두 라이브러리가 내가 사용하는 방식으로 호환되어야합니까?

Answer 1

많은 플랫폼에서 컴파일러가 준수해야하는 게시 된 ABI 문서가 있습니다. C++과 그 플랫폼 ABI 위에는 Itanium C++ ABI이 있습니다. Itanium은 이제 더 이상 Itanium과 관련이 없으며 Itanium이 컴퓨팅에 지속적으로 기여할 것입니다.

그러나 이것은 라이브러리에는 적용되지 않습니다. 리눅스 용 libc가 많이 있으며, glibc에 컴파일되고 링크 된 것은 Bionic libc (안드로이드)에서 실행되지 않으며 그 반대의 경우도 아키텍처가 일치하더라도 마찬가지입니다. 기본적으로 C++ 표준 라이브러리에는 똑같은 것이 적용됩니다 (GCC와 함께 제공되는 구현에는 약간 다른 ABI가 옵션으로 제공됩니다).

ARM을 사용하면 상당한 양의 하위 아키텍처 변형이 있습니다.

요약은 다음과 같습니다. 모든 사람이 노력할 때 당신이하려는 것은 효과가 있습니다. 그렇지 않은 경우 아마 그렇지 않습니다. C++에 대한 권리를 얻는 것이 C보다 어렵습니다.