“No such file or directory” linker error, LD_LIBRARY_PATH set correctly

Question

Some background: I'm using an embedded board (the SolidRun Cubox-i4 Pro), and have installed Ubuntu 14.04 on it using an image obtained on SolidRun's community forums.

This particular board has a Vivante GC2000 graphics driver that advertises OpenCL support. However, the GPU driver is proving to be a pain. I found binaries for all the required libraries, but when I try to run a small test executable built against them, I get this familiar error:

cubox@cubox:~/cltest$ g++ cltest.cpp -lOpenCL -lGAL
cubox@cubox:~/cltest$ ./a.out 
./a.out: error while loading shared libraries: libOpenCL.so: cannot open shared object file: No such file or directory

So I double-check the path of the library:

cubox@cubox:~/cltest$ ls /usr/lib/libOpenCL*   
/usr/lib/libOpenCL.so

And I double-check my LD_LIBRARY_PATH variable:

cubox@cubox:~/cltest$ echo $LD_LIBRARY_PATH
/usr/lib

OK, so clearly the issue is not that it can't find the library, but that there's some kind of incompatibility, and the error is being misleading (I've seen this before). So I try this:

cubox@cubox:~/cltest$ file /usr/lib/libOpenCL.so 
/usr/lib/libOpenCL.so: ELF 32-bit LSB  shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped

...and compare that with what I just compiled:

cubox@cubox:~/cltest$ file a.out 
a.out: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=fcd06f947198f92f43f364874fcef66a6303e7b4, not stripped

They look similar, except that one mentions for GNU/Linux 2.6.32 . I then remembered that the driver came with some pre-compiled test apps, so I ran one of them:

cubox@cubox:/opt/viv_samples/cl11/fft$ ./fft 
-bash: ./fft: No such file or directory

...and checked its file info:

cubox@cubox:/opt/viv_samples/cl11/fft$ file fft
fft: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, stripped

So one is for GNU/Linux 2.6.32 , and the other is for GNU/Linux 2.6.31 .

Questions:

1. Is that why nothing will execute or "find" the libraries?
2. If so, what are my options? Can I force them to run somehow?
3. Is there another command I can run to learn more about the libraries?

EDIT in response to answer(s):

ldd output:

cubox@cubox:~/cltest$ ldd a.out 
    libOpenCL.so => not found
    libGAL.so => not found
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76ea1000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76e80000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76d99000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76d2c000)
    /lib/ld-linux-armhf.so.3 (0x76f5f000)

Executable permissions were already correct ( -rwxrwxr-x for mine, -rwxr-xr-x for the fft app).

Answer 1

run ldd on your executable to check what shared libraries it wants to pull in.

Also, to run a program it needs an executable bit to be set in the permitions

$ ls -la fft

$ chmod a+x fft ./fft

Answer 2

Almost certainly the problem is that you didn't export LD_LIBRARY_PATH so it's only set in your shell and not exported to the a.out child process.

See LD_LIBRARY_PATH, the shared lib path in linux