로컬로 설치된 공유 라이브러리 (./vendor/lib/libfoo.so
)를 내 바이너리 ./bar
에 연결하려고합니다. 아쉽게도 내 시도 중 어느 것도 절대 경로가 libfoo.so
인 링크를 생성하지 않습니다. 결과적으로 나는 이것을 피하기 위해LD_RUN_PATH없이 공유 라이브러리의 절대 경로를 지정하십시오.
LD_LIBRARY_PATH=vendor/lib ./bar
을 사용해야합니다. ldd bar
나에게 보여줍니다이 :
linux-vdso.so.1 => (0x00007ffed5fd8000)
libbar.so.2 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb9ea787000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb9ea47d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb9ea267000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9e9e9d000)
/lib64/ld-linux-x86-64.so.2 (0x000055f326761000)
단어에 대한 libbar.so.2
: 파일이 libbar.so
과 함께 (vendor/lib
에) 존재한다. 둘 다 실제로는 libhts.so.1.6
의 심볼릭 링크입니다. 이 파일도 존재하며 실제 공유 라이브러리입니다.
여기에 내가 시도한 다른 방법으로는 다음과 같습니다 이러한 변형의
FULL_PATH="$(pwd -P)/vendor/lib"
g++ -o bar bar.o -Lvendor/lib -lfoo # 1
g++ -o bar bar.o -L$FULL_PATH -lfoo # 2
g++ -o bar bar.o $FULL_PATH/libfoo.so # 3
g++ -o bar bar.o $FULL_PATH/libfoo.so.1.6 # 4
모든이 동일 ldd
출력을 생성, 심지어 마지막 줄은 (ld
도서관의 가장 높은 버전을 사용하여 주장 하는가?).
내가이 일을하기 위해 찾은 유일한 방법은 (g++
의 내 버전이 인수를 이해하지 않기 때문에 나는 -rpath
을 사용할 수 없습니다, 나는 g++
을 사용하고
LD_RUN_PATH=$FULL_PATH g++ -o bar bar.o -Lvendor/lib -lfoo
을 사용하는 것입니다 . 나는 물론 -Wl,-rpath
을 사용할 수 있습니다)
하지만 도움이되지만 환경 변수/-rpath
를 사용하지 않고이 일을 만드는 방법이있을 것을 느낄 수 - 대신 ld
의 된 libstdC++ 의존성이 바로 얻을 수 있습니다. 내가 an answer specifically referencing symlinks to libraries을 발견했지만 불행히도 그것은 나를 돕지 않는다. (위의 시도 4 참조).
이것은 우분투 16.04, g ++ 5.4.0, GNU ld 2.26.1에 있습니다.
"런타임 링커는'libfoo.so'가'/ what/ever/vendor/lib'에 있다는 사실을 모를 겁니다."- 바로 그 이유 때문에, 바이너리를 라이브러리를 사용하여'ld.so'가 그것을 검색 할 필요가 없다 (나는 슈퍼 유저 권한이 없다). 그러나 나는'-rpath'가 여기에있는 전통적인 해결책임을 알기 시작했다; 나는'ld'이 명시 적으로 절대 경로를 사용하는 것을 무시하는 이유에 대해 의아해했습니다. –