在 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.so .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，或者添加包装器 shell 脚本以LD_LIBRARY_PATH在调用二进制文件时进行设置。