首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >dnf被安装打破了-- /usr/lib64 64是如何进入搜索路径的,为什么不早一点呢?

dnf被安装打破了-- /usr/lib64 64是如何进入搜索路径的,为什么不早一点呢?
EN

Unix & Linux用户
提问于 2020-08-27 10:47:17
回答 1查看 1.6K关注 0票数 0

在centos8上安装RPM之后,我发现包管理器dnf -莫名其妙地停止了处理一个神秘错误:

代码语言:javascript
运行
复制
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 "", line 994, in _gcd_import
File "", line 971, in _find_and_load
File "", line 955, in _find_and_load_unlocked
File "", line 658, in _load_unlocked
File "", line 571, in module_from_spec
File "", line 922, in create_module
File "", 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 
from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/init.py", line 30, in 
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 29, in 
import libdnf.transaction
File "/usr/lib64/python3.6/site-packages/libdnf/init.py", line 3, in 
from . import common_types
File "/usr/lib64/python3.6/site-packages/libdnf/common_types.py", line 17, in 
_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 64中的系统版本。

因此,我的问题是,why是/usr/lib64 64,而不是在搜索路径上比ld.so.conf中的条目早,我找不到/usr/lib64 64配置的位置。它是硬编码到LD还是内核?

注意,/usr/lib64 64/libdnf.so.2已经在/usr/lib64 64中了,那么为什么不首先搜索/usr/lib64 64?

我的修正是将/usr/ fix 64的条目添加到ld.so.conf中。这是最好的办法吗?我认为/opt/使用RPATH查找库而根本不向ld.so.conf添加任何内容可能更好。

这如何适用于:

EN

回答 1

Unix & Linux用户

回答已采纳

发布于 2020-08-27 12:46:14

为什么搜索路径上的/usr/lib64 64不早于ld.so.conf中的条目

在没有任何其他配置的情况下,系统库路径是搜索路径上的最后一个条目。

我找不到配置/usr/lib64 64的位置。是硬编码到LD还是内核?

它是在动态链接器ld.so中进行硬编码的(在您的情况下,假设您在x86_64上)。详情请参见LD的默认值是多少?_图书馆_小径?

您的修复可能是最好的,您可以不触及包的内容。正如您所说,更好的解决方法是设置包的二进制文件的rpath,或者在调用二进制文件时添加包装外壳脚本来设置LD_LIBRARY_PATH

票数 1
EN
页面原文内容由Unix & Linux提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://unix.stackexchange.com/questions/606605

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档