centos8에 RPM을 설치한 후 패키지 관리자 dnf가 알 수 없는 오류로 인해 작동이 멈춘 것을 발견했습니다.
Traceback (most recent call last):
File "/usr/lib64/python3.6/site-packages/libdnf/common_types.py", line 14, in swig_import_helper
return importlib.import_module(mname)
File "/usr/lib64/python3.6/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 658, in _load_unlocked
File "<frozen importlib._bootstrap>", line 571, in module_from_spec
File "<frozen importlib._bootstrap_external>", line 922, in create_module
File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
ImportError: /lib64/libdnf.so.2: undefined symbol: sqlite3_expanded_sql
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/init.py", line 30, in <module>
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 29, in <module>
import libdnf.transaction
File "/usr/lib64/python3.6/site-packages/libdnf/init.py", line 3, in <module>
from . import common_types
File "/usr/lib64/python3.6/site-packages/libdnf/common_types.py", line 17, in <module>
_common_types = swig_import_helper()
File "/usr/lib64/python3.6/site-packages/libdnf/common_types.py", line 16, in swig_import_helper
return importlib.import_module('_common_types')
File "/usr/lib64/python3.6/importlib/init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_common_types'
머리를 긁적인 후에 나는 RPM이 libsqlite3.so의 자체 복사본을 /opt//lib의 경로에 설치하고 /opt//lib에 대한 항목을 설치 후 스크립트의 ld에 추가했기 때문에 문제가 있다는 것을 알아냈습니다. 그래서 .conf . 어떤 이유로 dnf는 일반적으로 사용하는 /usr/lib64의 시스템 버전 대신 이 버전을 선택합니다.
그래서 내 질문은/usr/lib64가 ld.so.conf의 항목 이전 검색 경로에 없는 이유는 무엇입니까? /usr/lib64가 구성된 위치를 찾을 수 없습니다. LD나 커널에 하드코딩되어 있나요?
/usr/lib64/libdnf.so.2는 이미 /usr/lib64에 있으므로 /usr/lib64를 먼저 검색해 보는 것은 어떨까요?
내가 해결한 방법은 /usr/lib64에 대한 항목을 ld.so.conf에 추가하는 것이었습니다. 이것이 최선의 방법입니까? 내 생각에는 /opt/에 대해 RPATH를 사용하여 라이브러리를 찾고 ld.so.conf에 아무것도 추가하지 않는 것이 더 나을 것 같습니다.
이것이 어떻게 적합합니까?
답변1
검색 경로에서 /usr/lib64가 ld.so.conf의 항목보다 이전에 있지 않은 이유는 무엇입니까?
다른 구성이 없으면 시스템 라이브러리 경로가 검색 경로의 마지막 항목입니다.
/usr/lib64의 구성 위치를 찾을 수 없습니다. LD나 커널에 하드코딩되어 있나요?
이는 ld.so
동적 링커에 하드코딩되어 있습니다( /lib64/ld-linux-x86-64.so.2
귀하의 경우에는 이를 사용한다고 가정 x86_64
). 바라보다LD_LIBRARY_PATH의 기본값은 무엇입니까?더 알아보기.
패키지의 내용물을 건드리지 않고 수정하는 것이 아마도 최선일 것입니다. 말씀하신 것처럼 더 나은 해결책은 패키지의 바이너리를 설정하거나 바이너리가 호출될 때 rpath
래퍼 쉘 스크립트를 추가하여 설정하는 것입니다.LD_LIBRARY_PATH