0

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)
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

  • 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! – Martin Thoma Dec 22 '15 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 Dec 23 '15 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 Dec 23 '15 at 3:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.