잘못된 공유 라이브러리가 링크되고 있습니다.

Question

라이브러리 (수정 됨)의 수정 된 버전과 연결을 시도하고 있습니다.

소스를 다운로드하고 수정 한 다음 공유 객체 파일을 작성합니다.

그런 다음 공유 라이브러리 파일을 링크하려는 프로젝트의 ./lib 폴더에 복사했습니다. 다른 프로젝트는 수정 작업을 테스트하는 간단한 도구였습니다. 나는 또한 LAME의 ./include에서 관련 머리글을 복사했습니다.

나는 나의 하네스 내장 :

gcc -c src/harness.c -o obj/harness.o 
gcc obj/harness.o -o bin/harness -L./lib/ -libmp3lame 

을하지만 내 깜짝에게 :

$ ldd ./bin/harness 
linux-vdso.so.1 => (0x00007fffbc5fe000) 
libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f10d9468000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10d90a0000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10d8d9b000) 
/lib64/ld-linux-x86-64.so.2 (0x00007f10d9713000) 

합니다 (/usr/lib/... 라이브러리 대신 프로젝트 디렉토리 '하네스에 ./lib에서 하나의 연결되었다

.

그런 다음 사용자 정의 된 libmp3lame.so의 이름을 libsomeothername.so로 변경하고 연결하려고했습니다. 동일한 문제가 발생했습니다. 내 사용자 정의 libmp3lame이 링크되었습니다.

여기에 무슨 일이 일어나고 있습니까? 왜 컴파일러는 말한대로하지 않습니까? 해당 이름을 사용하지 않을 때 /usr/lib/.../libmp3lame이 연결된 이유는 무엇입니까 ?

Answer 1

ld-linux.so 라이브러리는 런타임에 어떤 라이브러리가 링크되는지 실제로 제어하는 ​​라이브러리입니다. 반면에 GCC에 대한 -L 옵션은 라이브러리에 대한 컴파일 타임 검색 경로에만 영향을 미칩니다.

남자 페이지는 말한다 :

라이브러리 의존성을 해결, 동적 링커가 처음 슬래시를 포함하는 라이브러리 경로 이름에 지정된 경우는이 발생할 수 있습니다 슬래시 (포함되어 있는지 확인하기 위해 각 종속 문자열을 검사 링크 시간). 슬래시가 발견되면 종속성 문자열은 (상대 또는 절대) 경로 이름으로 해석되고 해당 경로 이름을 사용하여 라이브러리가로드됩니다.

슬래시가 없으면 미리 정의 된 검색 경로 (설명서 페이지에도 지정되어 있음)를 따라 검색합니다.

원하는 behaivour을 얻으려면, 당신은 다음과 같은 옵션이 있습니다 연결할 때

1. 라이브러리에 절대 경로를 지정하거나

2. 이 들어있는 디렉토리를 가리 키도록 LD_LIBRARY_PATH를 설정하십시오 라이브러리 또는

3. 라이브러리를 포함하는 디렉토리를 검색 경로에 포함 시키려면 링크 할 때 -rpath 옵션을 사용하십시오 (NB.링커에 GCC에서 링커 옵션을 전달하기 위해, LD_LIBRARY_PATH=...가 올바른 라이브러리에 연결해야 나는 링커에 무슨 일이 일어 났는지 볼 LD_DEBUG=all을 사용 -Wl,--rpath=/my/path

Answer 2

사용합니다.

링커 은 거기에 보이는 이었지만 거기에 있던 libmp3lame.so 대신에 libmp3lame.so.0가 발견 될 것으로 예상됩니다. 결국 .0으로 라이브러리의 이름을 변경하면 문제가 해결됩니다.

LD_LIBRARY_PATH=./lib ./bin/harness 

을 내가 원하는 lib 디렉토리 링크 :

지금 실행할 수 있습니다.

LD_DEBUG=all 매우 유용합니다.