왜 링커가 공유 라이브러리 이름을 변경합니까?

Question

'node-gyp'을 통해 전달 된 링커 명령 행 옵션 사용하기 프로그램과 연결할 라이브러리 경로와 라이브러리 이름을 지정합니다. 그러나 결과 실행 파일은 지정한 파일을 참조하지 않으므로 /usr/lib에서 다른 이름을 참조합니다.

binding.gyp의 라이브러리 섹션을 사용하여 로컬 lib 디렉토리를 참조하고 있습니다.

 'libraries': [ 
     '-lao-oboe', 
     '-L<(module_root_dir)/lib/', 
     '-Wl,-rpath-link,<(module_root_dir)/lib/', 
     '-Wl,-rpath,<(module_root_dir)/lib/' 
     ], 

node-gyp

내가 libao-oboe.so을 포함하지 않는 하나의 -L 경로를 변경하는 경우 링커가 /usr/bin/ld: cannot find -la-oboe을 반환하기 때문에 올바르게 옵션을 통과 할 것으로 보인다. 요청한 라이브러리의 이름을 lib의 이름과 다르게 변경하면 링커에서 오류를 반환합니다.

문제는 런타임시 로컬 라이브러리가로드되지 않는다는 것입니다. ldd은 node-gyp 출력 파일이 지정된 파일을 참조하지 않고 다른 이름의 라이브러리를 모두 참조하고 있음을 보여줍니다 (/usr/lib/liboboe-1.0.so.1).

lrwxrwxrwx 1 bruce bruce  15 Sep 8 02:50 libao-oboe.so -> libao-oboe.so.1` 
-rw-r--r-- 2 bruce bruce 1640848 Aug 31 15:01 libao-oboe.so.1 

그것은 로컬 라이브러리 파일이 libao-oboe.so.1가에서 참조되는 시스템 라이브러리 파일과 동일한 경우입니다 :

이

linux-vdso.so.1 => (0x00007ffee20f5000) 
liboboe-1.0.so.1 => /usr/lib/liboboe-1.0.so.1 (0x00007fa476377000) 
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa475ff5000) 
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa475c2b000) 
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa475a27000) 
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa47580a000) 
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa475501000) 
/lib64/ld-linux-x86-64.so.2 (0x00007fa476922000) 
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa4752eb000) 

지역 라이브러리 디렉토리가 포함되어 ldd 출력의 두 번째 줄을 참조하십시오 실행 파일 (ldd으로 표시) : /usr/lib/liboboe-1.0.so.1.

링커는 로컬 파일이 (해싱 또는 서명을 통해) 동일하고 표준 위치에서 라이브러리 파일을 대체한다는 것을 어떻게 알 수 있습니까?

node-gyp의 출력 파일이 빌드 프로세스의 일부로 요청되지 않은 라이브러리 파일을 참조하는 이유는 무엇입니까?

Answer 1

wikipedia - soname에 따르면 .so 파일의 SONAME 필드는 "기본 호환 버전"입니다. 위의 문제에서 발견 한 동작에서 명확한 점은 ld은 ld 명령에 지정된 파일 이름이 아닌 공유 라이브러리에 링크 된 파일에 SONAME을 삽입한다는 것입니다.

.so 파일의 이름을 바꾸어도 SONAME이 변경되지 않으므로 이름을 바꾼 파일에 연결된 실행 파일은 파일 이름이 아닌 SONAME 필드에 명명 된 라이브러리를로드하려고 시도합니다.

내 솔루션은 파일의 이름을 바꾸지 않았습니다.