PDA

View Full Version : Runtime error: can't find libGLEW.so.1.10 in /usr/lib64 directory



PrestoChung
08-27-2013, 09:30 PM
I'm having an error when trying to run my application. The file exists in the /usr/lib64 folder but I can't figure out how to fix the error


$ ./release/runme
./release/runme: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory
$ find /usr -name 'libGLEW*'
/usr/lib64/libGLEW.so.1.10.0
/usr/lib64/libGLEW.a
/usr/lib64/libGLEW.so
/usr/lib64/libGLEW.so.1.10
find: `/usr/lost+found': Permission denied
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.8.0
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.8
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.8
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.8.0
$ ldd ./release/runme
linux-vdso.so.1 => (0x00007fffd6388000)
libSDL2-2.0.so.0 => /usr/local/lib/libSDL2-2.0.so.0 (0x00007f2395f13000)
libSDL2_image-2.0.so.0 => /usr/local/lib/libSDL2_image-2.0.so.0 (0x00007f2395cee000)
libGL.so.1 => /usr/lib/nvidia-310/libGL.so.1 (0x00007f23959ca000)
libGLEW.so.1.10 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f23956c7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f23953c1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f23951ab000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2394de3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2394bc5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f23949c1000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f23947b9000)
libnvidia-tls.so.310.44 => /usr/lib/nvidia-310/tls/libnvidia-tls.so.310.44 (0x00007f23945b5000)
libnvidia-glcore.so.310.44 => /usr/lib/nvidia-310/libnvidia-glcore.so.310.44 (0x00007f23920c2000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f2391d88000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f2391b75000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2396222000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f2391957000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f2391752000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f239154c000)
$ ls -aR /usr/lib64/
/usr/lib64/:
. .. libGLEW.a libGLEW.so libGLEW.so.1.10 libGLEW.so.1.10.0 pkgconfig

/usr/lib64/pkgconfig:
. .. glew.pc

As you can see, the GLEW files are essentially the only things in the /usr/lib64 directory. I have issued the ldconfig command as root but that has not fixed the problem. It seems like something needs to be added to /etc/ld.so.conf or one of the other conf files in /etc/ld.so.conf.d, or maybe I can just move these GLEW files into /usr/lib/x86_64-linux-gnu/ ?

GClements
08-28-2013, 04:11 AM
As you can see, the GLEW files are essentially the only things in the /usr/lib64 directory. I have issued the ldconfig command as root but that has not fixed the problem. It seems like something needs to be added to /etc/ld.so.conf or one of the other conf files in /etc/ld.so.conf.d, or maybe I can just move these GLEW files into /usr/lib/x86_64-linux-gnu/ ?
ldconfig only scans the directories which are listed in ld.so.conf, or in files included from it. If GLEW is the only library in /usr/lib64, that suggests that your Linux distribution doesn't use that directory, so ld.so.conf probably doesn't reference it. You can either modify ld.so.conf or move the GLEW libraries. If the libraries aren't part of the distribution, they should probably go somewhere under /usr/local rather than under /usr.

Dark Photon
08-28-2013, 05:49 AM
Also, verify that your application is 64-bit, not 32-bit (run "file ./release/runme"). If it's 32-bit, it's not going to link with those 64-bit libs no matter what you do.

Assuming it is 64-bit though, GClements has you covered. You can test to see if those libs would work but just aren't being searched with "env LD_LIBRARY_PATH=/usr/lib64 ./release/runme". If that works, then it's just updating your dynamic link library path cache, and he tells you how. If it doesn't, then I would "ls -l /usr/lib64/libGLEW*" and verify that libGLEW.so.1.10 is an actual file, or is a symlink that points (directly or indirectly) to the actually file ... probably /usr/lib64/libGLEW.so.1.10.0.

PrestoChung
08-28-2013, 10:35 AM
Okay I was able to do something I think is equivalent to 'env LD_LIBRARY_PATH=/usr/lib64 ./release/runme: I use Scons for building and was able to set an environment variable RPATH = '/usr/lib64' in my Sconscript file. With this modification after rebuilding I was able to run with no errors.

When I finally do try and distribute the application should the library files such as libGLEW be moved into the executable directory itself? (assuming it's being run from a machine that hasn't built GLEW from makefile)

thokra
08-28-2013, 04:40 PM
Which distro, if I may ask?

PrestoChung
08-28-2013, 07:17 PM
Just moved from Mint 12 to Mint 15

thokra
08-29-2013, 01:44 AM
32-bits/64-bits? I guess, since you have a /usr/lib64 directory, you're running a 32-bit version. If so, why? Do you have a specific requirement to run a 32-bit installation? Did you install GLEW from the repo or compiled it yourself?

GClements
08-29-2013, 02:34 AM
When I finally do try and distribute the application should the library files such as libGLEW be moved into the executable directory itself? (assuming it's being run from a machine that hasn't built GLEW from makefile)
No. Linux isn't windows. Applications don't get packaged inside a single directory. Binaries go in "bin", libraries in "lib" (or lib32/lib64 on multi-arch setups), etc. Note that the loader won't, by default, search the directory containing the executable for libraries.
As Mint has an official package for GLEW, you shouldn't be bundling it, nor linking against a version which you built yourself.

PrestoChung
08-30-2013, 04:42 PM
As Mint has an official package for GLEW, you shouldn't be bundling it, nor linking against a version which you built yourself.

Silly me, I didn't even search for glew packages. I'm guessing the one I wanted was libglew-dev.




32-bits/64-bits? I guess, since you have a /usr/lib64 directory, you're running a 32-bit version. If so, why? Do you have a specific requirement to run a 32-bit installation? Did you install GLEW from the repo or compiled it yourself?

No it's the 64 bit version. I just went to the glew website and it didn't mention using apt/aptitude so I just downloaded the zip and ran 'sudo make install' from the directory. This created the lib64 directory and the glew files were the only files in there.

thokra
08-30-2013, 07:01 PM
sudo apt-get install libglew-dev

(since quantal. before it'd be libglew1.6-dev or libglew1.5-dev)

PrestoChung
08-30-2013, 10:27 PM
sudo apt-get install libglew-dev

(since quantal. before it'd be libglew1.6-dev or libglew1.5-dev)

Err, yeah I was about to do this, but I realized I don't know how to revert what I've done by running make install with the glew makefile... It's working for now, should I just leave it, or try and clean up before doing the proper package install?

Update:

Ok I was able to do 'sudo make uninstall' and install with apt. Thanks!

thokra
08-31-2013, 03:50 AM
Just to spare you further confusion, read up on makefiles (http://en.wikipedia.org/wiki/Make_%28software%29). It's very advantageous to at least understand how to use them.

GClements
08-31-2013, 05:54 AM
Silly me, I didn't even search for glew packages. I'm guessing the one I wanted was libglew-dev.
For development, you typically need both the "base" package (e.g. libglew) and the -dev package (e.g. libglew-dev), although installing the latter will probably install the former automatically. End users will only need the base package to run the program.