바이너리의 라이브러리 위치를 어떻게 지정합니까? (리눅스)


33

이 질문에 대해서는 특정 예제를 사용하지만 실제로는 종속 라이브러리를 찾을 수없는 Linux의 거의 모든 바이너리로 일반화됩니다. 따라서 라이브러리가 없어서 실행되지 않는 프로그램이 있습니다.

./cart5: error while loading shared libraries: libcorona-1.0.2.so: cannot open shared object file: No such file or directory

ldd는이 문제에 대해 다음과 같이 밝힙니다.

linux-vdso.so.1 =>  (0x00007fff18b01000)
libcorona-1.0.2.so => not found
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/libstdc++.so.6 (0x00007f0975830000)
libm.so.6 => /lib/libm.so.6 (0x00007f09755af000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0975399000)
libc.so.6 => /lib/libc.so.6 (0x00007f0975040000)
libz.so.1 => /lib/libz.so.1 (0x00007f0974e2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0975b36000)

그러나 코로나가 설치됩니다.

oliver@human$ find / -name libcorona-1.0.2.so 2> /dev/null

/usr/local/lib64/libcorona-1.0.2.so
/home/oliver/installed/corona-1.0.2/src/.libs/libcorona-1.0.2.so

바이너리가 "누락 된"라이브러리를 찾을 수있는 곳을 어떻게 알 수 있습니까?

답변:


43

한 번만 사용하려면 변수 LD_LIBRARY_PATH를 콜론으로 구분 된 검색 할 디렉토리 목록으로 설정하십시오 . 이는 PATH표준 시스템 디렉토리가 환경을 통해 지정된 디렉토리 이후에 추가로 검색된다는 점을 제외하고 실행 파일 과 유사 합니다.

LD_LIBRARY_PATH=/usr/local/lib64 ./cart5

라이브러리를 비표준 위치에 유지하고 자체적으로 라이브러리를 찾을 수없는 프로그램이있는 경우 랩퍼 스크립트를 작성할 수 있습니다.

#!/bin/sh
if [ -n "$LD_LIBRARY_PATH" ]; then
  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
else
  LD_LIBRARY_PATH=/usr/local/lib64
fi
export LD_LIBRARY_PATH
exec /path/to/cart5 "$@"

표준 시스템 디렉토리 목록은에 보관되어 /etc/ld.so.conf있습니다. 최근 시스템에서는이 파일에 다른 파일을 포함시킬 수 있습니다. 와 같은 것이 있으면 추가하려는 디렉토리를 포함하는 include /etc/ld.so.conf.d/*.conf이라는 새 파일을 만듭니다 /etc/ld.so.conf.d/mala.conf. 변경 /etc/ld.so.conf또는 포함 된 파일 을 변경 한 후 변경 /sbin/ldconfig사항을 적용하려면 캐시를 실행하십시오.

( LD_LIBRARY_PATH도. FreeBSD의, NetBSD의, 오픈 BSD, Solaris 및 Tru64를 포함한 많은 다른 유닉스에 적용 HP-UX는이 SHLIB_PATH와 Mac OS X이있다 DYLD_LIBRARY_PATH. /etc/ld.so.conf대부분의 유닉스에 아날로그를 가지고 있지만 위치와 구문은 더 널리 다릅니다.)


1
환상적입니다. 대단히 감사합니다. /etc/ld.so.conf에 대해 전혀 몰랐으며 앞으로 나에게 매우 유용 할 것입니다.
Mala

15

LD_LIBRARY_PATH를 피하려면 링크 중에이를 수행 할 수도 있습니다.

gcc -o exename -L/path/to/dynamiclib/ -lnameofLib \
    -Wl,-R/path/to/dynamiclib/ sourceCode1.c ...

-Wl, ...은 추가 명령을 링커에 전달하는 데 사용되며,이 경우 -R을 사용하면이 경로를 .so의 "기본 검색 경로"로 저장하도록 링커에 지시합니다.

나는 내 사이트에서 이와 같은 많은 작은 팁을 기록합니다.

https://www.thanassis.space/tricks.html


그러나 문제의 라이브러리 자체가 공유 라이브러리를 조회 할 경우 바이너리에 저장된 rpath는 하위 라이브러리 조회에 재귀 적으로 적용되지 않습니다. 환경에서 LD_LIBRARY_PATH를 설정하는 것 외에 다른 방법을 찾지 못했습니다. 그러면 재귀 조회에 적용됩니다 ...
Ethan

@Ethan : 맞습니다. 그러나 사실은 바이너리에 대한 공유 라이브러리를 "패키지"하려는 일반적인 시나리오는 모두 함께 배치 한 시나리오입니다. 예를 들어에 /opt/mypackage/bin/someBinary저장 한 라이브러리가 필요합니다 /opt/mypackage/lib/. / opt에 설치된 거의 모든 독점 SW가이 규칙을 따릅니다. 즉, 위에 표시된 방식으로 이러한 모든 설치를 처리 할 수 ​​있습니다. 그런 다음 일반적으로 / usr / bin 아래에 / opt 아래의 바이너리를 가리키는 심볼릭 링크를 추가합니다. "기본 검색 경로"가 .so해당 /opt/.../lib폴더 에서 s 를 찾을 수 있다는 것을 알고 있습니다 .
ttsiodras

그래, 내 경우에는 내가 (하지만 패키지가 어떤 상호 의존성 여러 내부 .so를 용의 ... 해결 방법의 다양한하지만 단지 성가신했다) ... 그 빌드 디렉토리에 링크가 아닌 설치하여 패키지를 테스트하고자했다
이단

0

이는 libcorona가 올바른 경로에 설치되지 않았 음을 나타냅니다. libcorona 디렉토리를 올바른 경로로 이동하면 문제가 해결됩니다.


이것은 다른 답변보다 어떻게 낫습니까?
Toto

@Toto 다른 답변과 달리 기본적으로 파일을 수동으로 설치하는 것입니다. 그렇지만이 답변이 더 낫다는 것을 의미하지는 않지만 고려해야 할 옵션입니다 (사람들은 Windows에서도 라이브러리를 복사 하여이 작업을 수행합니다) 앱을 찾을 수없는 경우 system32 / sysWOW64)를 권장하지 않습니다. 권장하지 않습니다. 권장하지 않습니다.
Tcll
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.