2017-10-26 1 views
2

로컬로 설치된 공유 라이브러리 (./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에 있습니다.

답변

1

그것은 당신이 표준이 아닌 위치에 공유 라이브러리를 설치 한 후 ldconfig 캐시를 업데이트하지 않았습니다 가능성이 소리 /what/ever/vendor/lib : -

sudo ldconfig /what/ever/vendor/lib 

당신은 런타임 링커가 될 것이라고 할 때까지 모르고 그 libfoo.so 실행시에 LD_LIBRARY_PATH 환경 변수를 통해 프롬프트를 표시하지 않는 한 은 /what/ever/vendor/lib입니다.

덧붙여 말하자면 이 -rpath을 인식하지 못하는 것은 g++ 버전의 단점이 아닙니다. 이것은 링커 (ld) 옵션 인 이 아니며 GCC 프론트 엔드 옵션이 아닙니다. 밖으로의 건물이 고려 될 수있다 일반적인 연계 잘 들어 ldconfig 캐시 또는 LD_LIBRARY_PATH

중 하나를에 의존 피하기 위해 그래서 -Wl,-rpath=/what/ever/vendor/lib은 프로그램에 표준이 아닌 런타임 라이브러리 경로를 시침의 기존의 방법입니다 차별 효과가 적은 ldconfig 캐시를 확장하지 말고 -rpath 을 사용하십시오.

+0

"런타임 링커는'libfoo.so'가'/ what/ever/vendor/lib'에 있다는 사실을 모를 겁니다."- 바로 그 이유 때문에, 바이너리를 라이브러리를 사용하여'ld.so'가 그것을 검색 할 필요가 없다 (나는 슈퍼 유저 권한이 없다). 그러나 나는'-rpath'가 여기에있는 전통적인 해결책임을 알기 시작했다; 나는'ld'이 명시 적으로 절대 경로를 사용하는 것을 무시하는 이유에 대해 의아해했습니다. –

관련 문제