Building executables that run in the future (after updating shared libraries)

#1

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.

My questions:

  • Could my app be linked against libGLEW.so instead 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.1 or 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.

#2

The only way to make binaries to work across different versions is to either link everything statically which is not easily supported by any of the OF build systems or to create some kind of container like appimage or even something like docker so the final binary contains all it’s dependencies.

Other distros like debian don’t change the libraries versions accros one version lifecycle which ensures that this doesn’t happen as long as you are using the same version of the OS but with archlinux they constantly change libraries so you need to have the exact same libraries to be able to run a binary from one computer into another or after some time.

In any case unless you want to distribute your program as a binary to other people i would just recompile the application.

#3

Thank you, I’ll work on making it easy to compile all the sketches :slight_smile:

#4

is it possible to use [appImage] ( https://appimage.org/) or rather create an appimage for a OF compiled application have you try it ??

#5

I think it’s should be possible but have never tried it

#6

Let us know how it goes :wink:

#7

so it actually works you just have to do this
Create an AppDir structure that looks (as a minimum) like this:


MyApp.AppDir/
MyApp.AppDir/AppRun    --- you donwnload this from [here](https://github.com/AppImage/AppImageKit/releases) get the one AppRun-x86_64 and just renamed to AppRun
MyApp.AppDir/myapp.desktop
MyApp.AppDir/myapp.png
MyApp.AppDir/usr/bin/myapp --- copy your OF app here  i copied  the bin folder complete
MyApp.AppDir/usr/lib/libfoo.so.0 -- din't know what to do with this but i   copy ibfmodex.so   here also 

you have to make de MyApp.AppDir/myapp.desktop file like this

[Desktop Entry]
Name=MyApp
Exec=myapp
Icon=myapp
Type=Application
Categories=Utility;

and then just download the appimagetool-x86_64.AppImage and run the appimage tool to your MyApp.AppDir
and it works i will look into making an extension for VsCode that will be awesome to have will be just like working on Xcode on mac hopefully

#8

With this approach the program should still run even after updating system libraries right?

#9

I have tested with two different manjaro one updated and the other one not so much and it worked fine so far

#10

a reliable test would be to try a normal application compiled in one of the two, in both systems. if it doesn’t work in one of them and the appimage one does then it means that this method can work accross versions

i’m a bit skeptic to be honest, OF applications have dependencies with dynamic libraries like Xorg that come with the system and are incompatible between versions since they depend on the local libstd + a lot of other dependencies. For this to work you would need to pack a lot of .so libraries that unless the appimage tool is detecting and packaging automatically you are not adding in your packages