linux 中添加自己的库路径的方法 cannot open shared object file: No such file or directory

本文介绍在Linux系统中如何配置库文件的搜索路径,包括通过环境变量LD_LIBRARY_PATH和编辑/etc/ld.so.conf文件两种方式,并解释了ldconfig的作用。

本文转自:http://blog.youkuaiyun.com/maotianwang/article/details/44619197

库文档在连接(静态库和共享库)和运行(仅限于使用共享库的程式)时被使用,其搜索路径是在系统中进行配置的。一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径,所以使用这两个目录中的库时无需进行配置搜索路径即可直接使用。对于处于默认库搜索路径之外的库,需要将库的位置添加到库的搜索路径之中。配置库文档的搜索路径有下列两种方式,可任选其一使用:

    在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。

    在 /etc/ld.so.conf 文档中添加库的搜索路径。

    将自己可能存放库文档的路径都加入到/etc/ld.so.conf中是明智的选择

    添加方法也极其简单,将库文档的绝对路径直接写进去就OK了,一行一个。例如:

    /usr/X11R6/lib

    /usr/local/lib

    /opt/lib

    需要注意的是:第二种搜索路径的配置方式对于程式连接时的库(包括共享库和静态库)的定位已足够了,但是对于使用了共享库的程式的执行还是不够的。这是因为为了加快程式执行时对共享库的定位速度,避免使用搜索路径查找共享库的低效率,所以是直接读取库列表文档 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是个非文本的数据文档,不能直接编辑,他是根据 /etc/ld.so.conf 中配置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文档集中在一起而生成的(ldconfig 命令要以 root 权限执行)。因此,为了确保程式执行时对库的定位,在 /etc/ld.so.conf 中进行了库搜索路径的配置之后,还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文档之后才能够。ldconfig ,简单的说,他的作用就是将/etc/ld.so.conf列出的路径下的库文档缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文档,(例如刚安装好glib),或修改ld.so.conf增加新的库路径后,需要运行一下 /sbin/ldconfig使任何的库文档都被缓存到ld.so.cache中,假如没做,即使库文档明明就在/usr/lib下的,也是不会被使用的,结果编译过程中抱错,缺少xxx库,去查看发现明明就在那放着,搞的想大骂computer蠢猪一个。

    在程式连接时,对于库文档(静态库和共享库)的搜索路径,除了上面的配置方式之外,还能够通过 -L 参数显式指定。因为用 -L 配置的路径将被优先搜索,所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。

    前面已说明过了,库搜索路径的配置有两种方式:在环境变量 LD_LIBRARY_PATH 中配置连同在 /etc/ld.so.conf 文档中配置。其中,第二种配置方式需要 root 权限,以改变 /etc/ld.so.conf 文档并执行 /sbin/ldconfig 命令。而且,当系统重新启动后,任何的基于 GTK2 的程式在运行时都将使用新安装的 GTK+ 库。不幸的是,由于 GTK+ 版本的改变,这有时会给应用程式带来兼容性的问题,造成某些程式运行不正常。为了避免出现上面的这些情况,在 GTK+ 及其依赖库的安装过程中对于库的搜索路径的配置将采用第一种方式进行。这种配置方式无需 root 权限,配置也简单:

    $ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

    能够用下面的命令查看 LD_LIBRAY_PATH 的配置内容:

    $ echo $LD_LIBRARY_PATH

    至此,库的两种配置就完成了。

转载于:https://www.cnblogs.com/babosa/p/9217862.html

### 解决 Linux 系统中 `cannot open shared object file: No such file or directory` 的问题 当遇到错误提示 `OSError: libopencv_world.so.4.4: cannot open shared object file: No such file or directory` 或类似的共享对象文件找不到的情况时,通常是因为系统未能正确加载所需的动态链接。以下是可能的原因以及解决方案: #### 1. **确认共享是否存在** 首先需要验证目标共享是否确实存在于系统中。可以通过以下命令查找指定的 `.so` 文件: ```bash find / -name "libopencv_world.so.4.4" 2>/dev/null ``` 如果未找到该文件,则说明缺少必要的依赖项。此时可以尝试重新安装相关软件包或手动下载并放置到适当位置。 对于 OpenCV 特定版本缺失的问题,可考虑通过官方源码编译或者使用包管理器安装对应版本[^1]: ```bash sudo apt-get update && sudo apt-get install libopencv-dev ``` #### 2. **更新动态链接器缓存配置** 即使存在所需共享,但如果其所在目录不在标准搜索路径范围内,仍会出现上述错误消息。因此需检查 `/etc/ld.so.conf` 配置文件及其关联子目录列表是否已包含自定义安装路径 (如 `/usr/local/lib`) 。如果没有,请执行如下操作将其添加进去,并刷新全局可见范围内的变更记录: ```bash echo "/usr/local/lib" | sudo tee -a /etc/ld.so.conf.d/usr_local_lib.conf >/dev/null sudo ldconfig ``` 此过程会通知操作系统新增加了一个潜在可用资源集合地址供后续调用解析参考依据[^2]。 #### 3. **虚拟环境冲突排查** 有时开发人员会在不同项目间切换频繁而导致某些特定框架内部组件相互干扰现象发生;特别是像 PyTorch 这样高度依赖 GPU 加速支持的技术栈更是如此。为了防止此类情况再次重现建议定期审查当前工作区下的全部第三方扩展模块清单以便及时发现异常状况的存在迹象: ```bash conda list | grep -E 'torch|cuda' ``` 理想状态下应该仅仅展示那些源自于可信供应商所提供的正式发行版条目而已而不是混杂着其他来源不明的东西在里面混淆视听造成困扰[^3]. 综上所述,针对本案例描述中的具体表现形式采取相应措施之后应当能够有效缓解乃至彻底消除之前所遭遇过的难题. ```python import cv2 print(cv2.__version__) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值