1

When I try to execute a framework for a university assignment, I get

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

I use a computer at university. That means I have no root access. However, if I can say what exactly is the problem the administrators might help me.

  • CUDA seems to be installed (nvidia-smi and nvcc --help both work).
  • libOpenCl.so exists on the system

Information about my system

$ echo $LD_LIBRARY_PATH
:/opt/cuda-7.5/lib64:/home/stud/s_thoma/cuda

$ echo $LIBGL_DRIVERS_PATH
:/home/stud/s_thoma/cuda:/opt/cuda-7.5/lib64:/home/stud/s_thoma/cuda

/opt/cuda-7.5/lib64$ ls
libcublas_device.a   libcuinj64.so.7.5.18   libnppi.so.7.5.18
libcublas.so         libculibos.a           libnppi_static.a
libcublas.so.7.5     libcurand.so           libnpps.so
libcublas.so.7.5.18  libcurand.so.7.5       libnpps.so.7.5
libcublas_static.a   libcurand.so.7.5.18    libnpps.so.7.5.18
libcudadevrt.a       libcurand_static.a     libnpps_static.a
libcudart.so         libcusolver.so         libnvblas.so
libcudart.so.7.5     libcusolver.so.7.5     libnvblas.so.7.5
libcudart.so.7.5.18  libcusolver.so.7.5.18  libnvblas.so.7.5.18
libcudart_static.a   libcusolver_static.a   libnvrtc-builtins.so
libcufft.so          libcusparse.so         libnvrtc-builtins.so.7.5
libcufft.so.7.5      libcusparse.so.7.5     libnvrtc-builtins.so.7.5.18
libcufft.so.7.5.18   libcusparse.so.7.5.18  libnvrtc.so
libcufft_static.a    libcusparse_static.a   libnvrtc.so.7.5
libcufftw.so         libnppc.so             libnvrtc.so.7.5.17
libcufftw.so.7.5     libnppc.so.7.5         libnvToolsExt.so
libcufftw.so.7.5.18  libnppc.so.7.5.18      libnvToolsExt.so.1
libcufftw_static.a   libnppc_static.a       libnvToolsExt.so.1.0.0
libcuinj64.so        libnppi.so             libOpenCL.so
libcuinj64.so.7.5    libnppi.so.7.5         stubs

~/cuda$ ls
libOpenCL.so.1

$ uname -a
Linux i08pc71 4.0.4-303.ATIS.aufs4.0.fc22.x86_64 #1 SMP Wed Jun 3 13:02:20 CEST 2015 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/issue
Fedora release 22 (Twenty Two)
Kernel \r on an \m (\l)

1 Answer 1

2

strace will help you to debug your issue. It will show you where dynamic linker looks for libOpenCL.so.1. Note that you may ended up with a broken symlink inside your ~/cuda directory.

To properly test for this, install or otherwise get an strace binary and then run:

strace -f -v -s150 ./Assignment 2>&1 | fgrep libOpenCL.so.1

3
  • pastebin.com/5VkCT95p is the output. Nice. Now I've just made a softlink in one of the folders to which I can write and it works. Thank you! Commented Dec 22, 2015 at 19:02
  • Your pastebin reveals another "hidden" LD_LIBRARY_PATH: the ELF RPATH feature. Your executable probably contains it and tries additionally to load the library from /home/stud/s_thoma/startupkit-a4linux/Assignment4.build/glew (it's probably your current working directory, or it comes from the executable). RPATH is a feature that permits shipping portable executables that can load libraries from current directory for example - it's LD_LIBRARY_PATH embedded into executable. You can examine that with readelf -d ./Assignment | fgrep RPATH.
    – user140866
    Commented Dec 23, 2015 at 3:16
  • It's not a bug but something you should be aware of. It does not hurt, but can potentially become a source of pains in future.
    – user140866
    Commented Dec 23, 2015 at 3:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .