컴퓨팅 · 실용 가이드
Linux의 “cannot open shared object file”: 라이브러리를 바꾸기 전에 로더 검색을 입증하세요
지정된 .so는 실제로 없거나 서비스 환경에서 보이지 않거나 캐시가 다르거나 ABI가 맞지 않을 수 있습니다. ldconfig, LD_LIBRARY_PATH, 파일 복사, 심볼릭 링크 전에 로더 원장을 만드세요.
“Error while loading shared libraries”는 런타임 로더가 의존성을 만족하지 못했다는 뜻이지 비슷한 이름의 파일이 없다는 증거가 아닙니다. 실제 실행 파일, ELF 인터프리터, DT_NEEDED, RUNPATH/RPATH, 환경, 캐시, 기본 디렉터리, 아키텍처, 서비스 또는 컨테이너 네임스페이스가 결과를 결정합니다.
수리는 소유권 결정입니다. 배포판이나 공급업체 패키지가 의존성을 소유하면 맞는 패키지를 복구하고, 자체 빌드가 소유하면 SONAME과 배포 경로를 고치세요. 호환성을 입증하지 않은 전역 경로나 주 버전 링크를 만들지 마세요.
1. 실제 실행 파일과 요청 이름을 캡처하세요
정확한 명령, 실행 경로, 사용자, 서비스/컨테이너, 작업 디렉터리와 오류를 기록하세요. 래퍼와 링크를 해석해 execve에 도달한 ELF를 readelf로 봅니다.
readelf -dW로 DT_NEEDED와 RPATH/RUNPATH를, readelf -lW 또는 file로 인터프리터와 플랫폼을 기록하세요.
2. 로더 검색을 재구성하세요
동일한 실행 문맥에서 인터프리터 --list 또는 적절한 LD_DEBUG=libs를 사용해 검색 경로와 첫 후보 또는 거부를 기록하세요.
내장 경로, 실제 LD_LIBRARY_PATH, 캐시와 기본 경로를 비교하세요. systemd, 컨테이너, sudo, set-user-ID는 환경이 다를 수 있습니다.
3. 후보와 소유자를 검증하세요
각 후보의 ELF 헤더와 동적 섹션을 검사해 클래스, 머신, 엔디언, SONAME, 심볼 버전을 맞추세요. 링크는 ABI를 호환되게 만들지 못합니다.
패키지 DB, 공급업체 명세나 빌드 산출물로 소유자를 찾고 업그레이드 삭제, 오래된 캐시, 불완전 이미지, 잘못된 아키텍처와 누락 런타임을 구분하세요.
4. 좁게 수리하고 깨끗한 시작을 입증하세요
소유 컴포넌트를 재설치하거나 재빌드하고 올바른 경로에 배포하세요. 자체 앱은 의도한 RUNPATH나 공식 로더 설정을 사용합니다.
임시 우회를 제거한 뒤 원래 서비스/컨테이너에서 다시 실행하고 해석된 객체, 시작, 아키텍처, 패키지 버전과 실제 기능을 확인하세요.
