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

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: 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/ ->
lrwxrwxrwx 1 root root     16 Aug  3 18:29 /usr/lib/ ->
-rw-r--r-- 1 root root 665608 Aug  3 18:29 /usr/lib/

I can make the program work again by doing this

$ sudo ln -s /usr/lib/ /usr/lib/

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 instead of a specific version like ? 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 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.

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.

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

is it possible to use [appImage] ( or rather create an appimage for a OF compiled application have you try it ??

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

Let us know how it goes :wink:

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

MyApp.AppDir/AppRun    --- you donwnload this from [here]( get the one AppRun-x86_64 and just renamed to AppRun
MyApp.AppDir/usr/bin/myapp --- copy your OF app here  i copied  the bin folder complete
MyApp.AppDir/usr/lib/ -- din't know what to do with this but i   copy   here also 

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

[Desktop Entry]

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

1 Like

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

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

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

I’ve been trying to make appImage out of a built OF app since yesterday, but so far I got it only to work on my same system (double-clicking the executable appImage) the same way you would run your compiled app (either release or debug).

That is, if I leave my .AppDir/usr/lib empty… (But then, tested on other linux distros via virtual machine, running the appImage in console reveals that it cannot find these .so.someNumber libraries)

I took the pain yesterday to copy all the needed .so files straight from usr/lib64 (cos that’s where they were located), renamed them to corresponding .so.someNumber filenames and tried to add them to usr/lib inside the .AppDir
If I add the .so.someNumber libraries to .AppDir/usr/lib , and make the appImage though, it won’t run even on my native system… The console is complaining about mount versions of the libraries not found.
(myGUI - the name of my test app running via console below:)

myGUI: /tmp/.mount_MyGUI-wXbJWF/usr/lib/ version `GLIBC_2.7' not found (required by /tmp/.mount_MyGUI-wXbJWF/usr/lib/
myGUI: /tmp/.mount_MyGUI-wXbJWF/usr/lib/ version `GLIBC_2.14' not found (required by /tmp/.mount_MyGUI-wXbJWF/usr/lib/
myGUI: /tmp/.mount_MyGUI-wXbJWF/usr/lib/ version `GLIBC_2.15' not found (required by /tmp/.mount_MyGUI-wXbJWF/usr/lib/
myGUI: /tmp/.mount_MyGUI-wXbJWF/usr/lib/ version `GLIBC_2.4' not found (required by /tmp/.mount_MyGUI-wXbJWF/usr/lib/
myGUI: /tmp/.mount_MyGUI-wXbJWF/usr/lib/ version `GLIBC_2.17' not found (required by /tmp/.mount_MyGUI-wXbJWF/usr/lib/
etc. etc. etc.

I copied the output here as a log: (2.4 KB)

What does it actually mean? Can it be circumvented somehow?

So I guess I’m pretty much returning to @hamoid 's original question, whether the OF project or the appImage could be forced to target just the .so files without the numbers (and in the .AppDir/usr/lib would be the .so files without numbers) in the build and/or in the process of AppImage creation ?