☰

无法加载库 libOpenCL.so.1，尽管它存在

tag-icon • tag-icon linux shared-library
无法加载库 libOpenCL.so.1，尽管它存在

我已经安装ocl-icd-opencl-dev并尝试运行一个简单的 OpenCL 应用程序，名为vadd：

$ ./vadd
./vadd: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory

我已关注这，输出如下所示（我只保留了有趣的部分）：

$ strace -f -v -s150 ./vadd 2>&1 | fgrep libOpenCL.so.1
...
open("/usr/lib/x86_64-linux-gnu/libOpenCL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...

出色地...

$ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
lrwxrwxrwx   1 root root       18 Dec 18  2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0

我在这里缺少什么？这libOpenCL.so.1是符号链接的问题吗？

答案1

就我而言，我刚刚打破了一些包裹。

首先检查你的文件包是否正常。

ls -la /usr/lib/x86_64-linux-gnu/libOpenCL*

如果您看到像这样的红色结果

lrwxrwxrwx   1 root root        18 abr  5  2017 libOpenCL.so -> libOpenCL.so.1.0.0

红色文本表示符号链接已损坏，目标丢失。然后你需要重新安装它。

赶紧跑

sudo apt --reinstall install ocl-icd-libopencl1

然后再做一次

ls -la /usr/lib/x86_64-linux-gnu/libOpenCL*
lrwxrwxrwx 1 root root    18 abr  5  2017 /usr/lib/x86_64-linux-gnu/libOpenCL.so -> libOpenCL.so.1.0.0
lrwxrwxrwx 1 root root    18 abr  5  2017 /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 -> libOpenCL.so.1.0.0
-rw-r--r-- 1 root root 43072 abr  5  2017 /usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0

是的！不再有红色文字了。您的libOpenCL.so.1.0.0文件现在存在。

答案2

问题不在于libOpenCL.so.1符号链接，而在于它是破碎的符号链接。

$ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
lrwxrwxrwx   1 root root       18 Dec 18  2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0

上面的输出仅显示指向“真实”文件的符号链接libOpenCL.so.1.0.0。但是，该文件应该存在于同一目录中，但它不可用。这就是ENOENT尝试读取文件时strace 输出报告的原因。

答案3

我设法解决了这个问题，所以我发布了我所做的事情，以防有人陷入同一个坑。

首先，我做过这里有一个损坏的符号链接：

$ ls -la /usr/lib/x86_64-linux-gnu/ | grep libOpenCL
lrwxrwxrwx   1 root root       18 Dec 18  2015 libOpenCL.so.1 -> libOpenCL.so.1.0.0

我通过以下方式安装了 OpenCL面向 OpenCL 应用的英特尔 SDK，而且我的安装有点混乱。

经过一番挖掘后我发现，Intel SDK 安装会安装 OpenCL 共享库（考虑到年份和版本的变化）/opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/。对于我的系统（Linux Mint），这是默认位置（在安装过程中唯一可以更改的是/opt/intel/）。事实上，它看起来像这样：

$ ls -l /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/ | grep libOpenCL
lrwxrwxrwx 1 root root        16 Aug 16 04:35 libOpenCL.so -> ./libOpenCL.so.1
lrwxrwxrwx 1 root root        18 Aug 16 04:35 libOpenCL.so.1 -> ./libOpenCL.so.2.0
-rwxr-xr-x 1 root root     48216 Sep 21  2018 libOpenCL.so.2.0

这意味着唯一的“实际”文件是libOpenCL.so.2.0并且有一系列符号链接：libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0。

此外，我发现 中有许多符号链接/etc/alternatives/，看起来相当不错（基本上，我的理解是它们解析库名称末尾的数字，并充当中间人，以防实际库发生变化- 正如我之前指出的，它们在我的系统中都是相同的）：

$ ls -l /etc/alternatives/ | grep OpenCL
lrwxrwxrwx 1 root root 115 Aug 16 04:35 opencl-libOpenCL.so -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so
lrwxrwxrwx 1 root root 117 Aug 16 04:35 opencl-libOpenCL.so.1 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1
lrwxrwxrwx 1 root root 119 Aug 16 04:35 opencl-libOpenCL.so.2.0 -> /opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0

因此，我能做的最简单的事情就是完全删除上面损坏的符号链接（只是rm）并创建 3 个新的符号链接，每个库名称末尾的数字一个，只是为了确保：

$ cd /usr/lib/x86_64-linux-gnu
$ sudo ln -s /etc/alternatives/opencl-libOpenCL.so libOpenCL.so
$ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.1 libOpenCL.so.1
$ sudo ln -s /etc/alternatives/opencl-libOpenCL.so.2.0 libOpenCL.so.2.0

现在，/usr/lib/x86_64-linux-gnu目录看起来像这样，一切似乎都正常：

$ ls -l /usr/lib/x86_64-linux-gnu/ | grep OpenCL
lrwxrwxrwx  1 root root       37 Aug 16 04:47 libOpenCL.so -> /etc/alternatives/opencl-libOpenCL.so
lrwxrwxrwx  1 root root       39 Aug 16 04:47 libOpenCL.so.1 -> /etc/alternatives/opencl-libOpenCL.so.1
lrwxrwxrwx  1 root root       41 Aug 16 04:35 libOpenCL.so.2.0 -> /etc/alternatives/opencl-libOpenCL.so.2.0

答案4

创建指向 libOpenCL.so.1 的符号链接 libOpenCL.so。就这样。

$ cd /usr/lib/x86_64-linux-gnu/
$ ln -fs libOpenCL.so.1 libOpenCL.so

相关内容