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.
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.
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)
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. 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.
As Mint has an official package for GLEW, you shouldn’t be bundling it, nor linking against a version which you built yourself.[/QUOTE]
Silly me, I didn’t even search for glew packages. I’m guessing the one I wanted was libglew-dev.
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.
(since quantal. before it’d be libglew1.6-dev or libglew1.5-dev)[/QUOTE]
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?
Ok I was able to do ‘sudo make uninstall’ and install with apt. Thanks!
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.