我已经安装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
是一个符号链接的问题吗?
问题不是
libOpenCL.so.1
符号链接,而是符号链接损坏。上面的输出只显示了指向“真实”文件的符号链接
libOpenCL.so.1.0.0
。但是,该文件应该存在于同一目录中,但它不可用。这就是ENOENT
尝试读取文件时 strace 输出报告的原因。我设法解决了这个问题,所以我发布了我所做的,以防有人掉进同一个坑。
首先,我在这里确实有一个损坏的符号链接:
我通过Intel SDK for OpenCL Applications安装了 OpenCL ,我在安装过程中有点搞砸了。
经过一番挖掘,我发现英特尔 SDK 安装安装了 OpenCL 共享库——考虑到年份和版本的变化——在
/opt/intel/system_studio_2019/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/
. 对于我的系统(Linux Mint),这是默认位置(在安装过程中您唯一可以更改的是/opt/intel/
)。事实上,它看起来像这样:这意味着唯一的“实际”文件是
libOpenCL.so.2.0
并且有一系列符号链接:libOpenCL.so -> libOpenCL.so.1 -> libOpenCL.so.2.0
.此外,我发现 中有许多符号链接
/etc/alternatives/
,看起来还不错(基本上,我的理解是它们解析了库名称末尾的数字并充当中间人,以防实际库发生变化- 正如我之前指出的,这在我的系统中都是一样的):所以,我能做的最简单的事情是完全删除上面损坏的符号链接(只是
rm
)并创建 3 个新符号链接,一个用于库名称末尾的每个数字,以确保:现在,
/usr/lib/x86_64-linux-gnu
目录看起来像这样,一切似乎都正常:就我而言,我刚刚弄坏了一些包裹。
首先,检查您的文件包是否正常。
如果您看到像这样的 RED 结果
红色文本表示符号链接已损坏,目的地丢失。然后你需要重新安装它。
赶紧跑
再做一次
是的!没有红色文字了。您的
libOpenCL.so.1.0.0
文件现在存在。创建一个指向 libOpenCL.so.1 的符号链接 libOpenCL.so。就这样。