저는 g ++를 사용하는 리눅스에서 C++ 응용 프로그램을 만들고 있습니다. 필자가 필요로하는 간단한 API를 제공하는 공유 라이브러리에서 내 앱 링크. 이 라이브러리는 많은 수의 추가 공유 라이브러리를 내부적으로 참조합니다. 나는 각각을 찾고 그것들을 내 Makefile에 추가하여 링크를 만들어야했다.링커 종속성 제거
내 응용 프로그램이 기본 lib가 의존하는 모든 libs에 링크해야한다고 가정합니다. 이 연결 요구 사항을 둘러싼 유일한 방법은 기본 lib를 모든 종속성의 정적 라이브러리에서 컴파일하는 것입니까? 이것은 dlopen/dlsym을 통해 플러그인 모델을 사용할 때 적용됩니까?
타이 나는 내 응용 프로그램이 기본 lib 디렉토리에 의존 libs와의 링크가 가정합니다. 이 연결 요구 사항을 둘러싼 유일한 방법은 기본 lib를 모든 종속성의 정적 라이브러리에서 컴파일하는 것입니까?
물론. 정적 링크이거나 라이브러리 런타임 검색 경로에 라이브러리 (올바른 버전, ABI와 호환되지 않는 경우)가있는 방법은 없습니다.
dlopen/dlsym을 통해 플러그인 모델을 사용할 때 적용됩니까?
아니요.이를 위해로드 할 경로에 공유 라이브러리가 있어야합니다.
기본 lib가 모든 종속성의 정적 라이브러리에서 컴파일되도록하는이 연결 요구 사항을 해결할 수있는 유일한 방법은 무엇입니까?
아니요. 공유 라이브러리는 자체가 의존하는 공유 라이브러리에 연결할 수 있습니다. 대부분의 링커는 해당 라이브러리를 선택하고 링커 단계에서 언급하지 않고도 해당 라이브러리에 실행 파일을 링크합니다.
공유 라이브러리가 필요한 라이브러리에 연결되지 않은 것처럼 들리는 경우가 있습니다. ldd 도구는 이와 관련하여 유용 할 수 있습니다.
gcc -shared foo.o -o libfoo.so -lm
가 이제 libfoo.so이 수학 라이브러리 (libm의)에 연결되어 있습니다 : 예를 들어
gcc -o prog main.o -lfoo
을해야 할 것 즉, 만에 제작되었다 응용 프로그램을 링크 할 때 명시 적으로 연결해야 할 것
gcc -shared foo.o -o libfoo.so
은 libm의하기 : 당신이) (공유 라이브러리를한다면 dlopen 때
gcc -o prog main.o -lfoo -lm
, 런타임 링커는 모든로드 라이브러리를 공유 한 라이브러리는 이미로드되지 않은 경우에도 링크되었습니다.따라서 dlopen() 라이브러리가 의존하는 라이브러리에 연결되어 있지 않고 실행 파일이 해당 라이브러리에 링크되어 있지 않으면 dlopen()이 실패합니다 (RTLD_LAZY를 지정하지 않으면 나중에 실패합니다)
내 응용 프로그램이 기본 lib에 의존하는 모든 libs에 연결해야한다고 가정합니다.
그것은 소리가 마치 하나의 앱은 바로 그 상징을 사용하고이 라이브러리에 연결되지 그래서 lib 디렉토리가 제대로 연결되지 않은 공유 또는 (단지 간접적으로 API 공유 lib 디렉토리를 통해) 그것은에 달려있다. 공유 라이브러리가 생성 된 경우 종속성은 -l으로 링크 된 경우 앱을 API 라이브러리에 연결할 때 자동으로 링크됩니다.
이 연결 요구 사항을 해결하는 유일한 방법은 기본 lib를 모든 종속성의 정적 라이브러리에서 컴파일하는 것입니다.
그건 한 가지 방법 일뿐, 유일한 방법은 아닙니다.
dlopen/dlsym을 통해 플러그인 모델을 사용할 때 적용됩니까?
은 긴 플러그인이 제대로 libs와 연결되어로 그들은 아니,이 경우 링커가 가능하면 실행시 dlopen을 것이다 LIBS 무엇인지 알 수 없다 ...에 따라, 그래서 알 수 없다 종속성이 무엇인지, 링크 타임에 이름을 지정할 필요가 없습니다. 로드 될 수있는 모든 플러그인을 미리 알지 못해서는 안됩니다.
플러그인 라이브러리가 제대로 연결되지 않은 경우 dlopen을 시도 할 때 동일한 문제가 발생합니다.