Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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)
share|improve this question
up vote 2 down vote accepted

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

share|improve this answer
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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