Hi! When executing any OF program from last year, they all fail to start in this way:
$ ./bla_debug ./bla_debug: error while loading shared libraries: libGLEW.so.2.0: cannot open shared object file: No such file or directory
If I look at my libs I see this:
$ ls -la /usr/lib/libGLEW* lrwxrwxrwx 1 root root 16 Aug 3 18:29 /usr/lib/libGLEW.so -> libGLEW.so.2.1.0 lrwxrwxrwx 1 root root 16 Aug 3 18:29 /usr/lib/libGLEW.so.2.1 -> libGLEW.so.2.1.0 -rw-r--r-- 1 root root 665608 Aug 3 18:29 /usr/lib/libGLEW.so.2.1.0
I can make the program work again by doing this
$ sudo ln -s /usr/lib/libGLEW.so /usr/lib/libGLEW.so.2.0
for all the libraries my program uses. But messing up the libraries folder like that sounds like a bad idea. Of course I could recompile my programs, but there’s many, and the libraries are updated frequently.
- Could my app be linked against
libGLEW.soinstead of a specific version like
libGLEW.so.2.0? I assume then the program might crash if the API’s of the libraries have changed. But I tried this a few times with
ln -s ...and it worked fine.
- Could I specify which library to use when launching the app? something like
$ ./bla_debug --useLib=libGLEW.so.2.1or something like that?
- Could I place a copy of the library in the app’s bin folder? I tried with no luck.
- How do I create an app that is more resistant to library updates?
- Should I forget about this and just focus on making it easy to recompile my programs?
I found this post, which deals with a similar issue but at the code level.