RPATH는 사용하고 RUNPATH는 사용하지 않습니까?

RPATH는 사용하고 RUNPATH는 사용하지 않습니까?

이 페이지는 라이브러리 검색 순서에 대해 설명합니다.ld.so:

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs

그리고 다음과 같이 제안합니다.

이진 파일을 전송할 때 RUNPATH가 아닌 RPATH를 사용하거나 실행하기 전에 LD_LIBRARY_PATH가 설정되어 있는지 확인합니다.

그래서, 사용.RPATH와 함께RUNPATH나쁜 이유는RUNPATH일종의 취소RPATH간접 동적 로딩이 예상대로 작동하지 않는 건가요?그런데 왜요?RPATH을 위해 퇴짜를 맞았습니다.RUNPATH?

누가 상황을 설명해 줄 수 있습니까?

바이너리를 발송할 때는 사용자가 자신의 시스템의 세부 사항에 맞게 바이너리를 수용할 수 있는 수단을 제공하는 것이 좋습니다. 특히 라이브러리 검색 경로를 조정하는 것이 좋습니다.

사용자는 일반적으로 조정할 수 있습니다.LD_LIBRARY_PATH그리고./etc/ld.so.conf둘 다 더 낮은 우선 순위를 가지고 있습니다.DT_RPATH즉, 바이너리에서 하드코드된 것을 재정의할 수 없습니다. 반면에, 만약 당신이 사용한다면.DT_RUNPATH대신, 사용자는 그것을 재정의할 수 있습니다.LD_LIBRARY_PATH.

(FWIW, 내 생각엔.ld.so.conf또한 보다 우선되어야 합니다.DT_RUNPATH하지만, 어쨌든, 적어도 우리는.LD_LIBRARY_PATH).

또한 저는 위의 제안을 사용하는 것에 강력히 반대합니다.DT_RPATHIMO, 둘 다 사용하지 않는 것이 좋습니다.DT_RPATH도 아니다DT_RUNPATH발송된 바이너리에서.

~하지 않는 한

모든 종속 라이브러리를 실행 파일과 함께 배송하고 설치 후 작업(tm)만 수행되도록 하려면 이 경우에 다음을 사용합니다.DT_RPATH.

Chill의 대답이 정확하게 맞습니다. 저는 glibc 소스([master 8b0ccb2], 2.17)의 최근 판독에서 약간의 색상을 추가하고 싶었습니다.지정된 수준에서 지정된 위치에 라이브러리가 없으면 다음 수준이 시도됩니다.지정된 수준에서 라이브러리를 찾으면 검색이 중지됩니다.

동적 라이브러리 검색 순서:

1. DT_RUNPATH가 설정되지 않은 경우 ELF 이진의 DT_RPATH입니다.
2. setuid/setgid를 제외한 LD_LIBRARY_PATH 항목
3. ELF 이진의 DT_RUNPATH
4. 링크 시 -z nodeflib가 지정되지 않은 경우 /etc/ld.so .cache 항목
5. -z nodeflib를 제외한 /lib, /usr/lib
6. 완료, "찾을 수 없습니다."

그런데 왜 RPATH는 RUNPATH를 선호하지 않게 되었습니까?

DT_RPATH가 도입되었을 때 다른 모든 매개 변수보다 우선했습니다.이로 인해 개발 목적으로도 라이브러리 검색 경로를 재정의할 수 없습니다.따라서 LD_LIBRARY_PATH보다 우선 순위가 낮은 또 다른 매개 변수 LD_RUNPATH가 도입되었습니다.

자세한 내용은 Ulrich Drepper가 작성한 "공유 라이브러리 작성 방법" 작업에서 확인할 수 있습니다.

언급URL : https://stackoverflow.com/questions/7967848/use-rpath-but-not-runpath