☰

/usr/lib 및 /etc/ld.so.conf.d

tag-icon • tag-icon symlink libraries shared-library dynamic-linking ldconfig
/usr/lib 및 /etc/ld.so.conf.d

긴 이야기 짧게에서 공유 라이브러리에 대한 심볼릭 링크를 배치하는 것이 더 나은 이유 /etc/lib(64)/또는 에서 *.conf 파일을 생성하는 것이 더 나은 이유/etc/ld.so.conf.d/

.conf 파일

/opt/foo/에 내 사용자 정의 바이너리가 있고 자체 공유 라이브러리가 함께 제공된다고 가정해 보겠습니다 . (내가 아는) 일반적인 방법은 /etc/ld.so.conf.d/foo.conf다음과 같이 파일을 배치하는 것입니다.

# Link foo libraries. This file is included in /etc/ld.so.conf
/opt/foo/lib
/opt/foo/otherlibs

그런 다음 ldconfig.

심볼릭 링크

/usr/lib하지만 다음과 같이 내 라이브러리를 (또는 lib64) 에 연결할 수도 있다는 것을 알았습니다 .

for f in /etc/foo/{lib,otherlibs}/*; do
  ln -s $f /usr/lib64/$(basename $f)
done

그 이후에는 더 이상 달릴 필요가 없습니다 ldconfig.

이 두 가지 방법의 장점/단점은 무엇입니까?

애플리케이션이나 라이브러리 버전을 업그레이드할 때 "symlink" 방식을 처리하기가 그리 쉽지는 않을 것 같습니다. 전반적으로 ".conf" 접근 방식은 나에게 더 모듈화되고 Linux에 가까운 것처럼 보입니다.

특정 라이브러리를 암호화(런타임에만 해독)해야 하기 때문에 가끔 이런 상황이 발생합니다. ldconfig암호화된 경우(여전히 ELF 형식) 라이브러리가 인식되지 않으므로 나에게 적합한 유일한 방법은 특정 *.so 파일에 대한 링크를 다음 위치에 넣는 것이었습니다./usr/lib64

답변1

일반적으로 "속하지 /usr않는 /usr/local" 모든 것은 배포판에 속합니다. 여기에 파일(심지어 심볼릭 링크)을 추가하는 것을 피해야 합니다.

새 구성 파일을 추가하면 /etc/ld.so.conf.d유지 관리가 더 쉽습니다. 변경 사항은 패키지 관리자에 의해 취소되지 않지만 모든 시스템 관리자가 쉽게 관리할 수 있습니다.

암호화 요구 사항을 깔끔하게 충족하는 것은 더 복잡합니다. 한 가지 접근 방식은 의 파일에 지정된 디렉터리에 스텁 라이브러리를 두고 /etc/ld.so.conf.d런타임 시 암호 해독을 처리하도록 하는 것입니다.

관련 정보