Linux problem please help [solved]

Hey @pandereto thanks for the question. I actually tried that solution and it didn’t work for me. Not sure if something was missing, I also deleted obj folder and .a file that @mr.Bitmap suggested.

Is this change already on 0.11.1 ? I can’t find this in the changelog. If it is, I can try again from a clean openFrameworks.

Not sure if is on 0.11.1, you can see is merged on github… is really extrange, please make sure you recompile of lib and your app. Maybe just download master brand and build from that to be sure or download 0.11.1 and check if change is there (in 0.11 still was not i think)

The flag that was removed was the cause of why “release dot not work and debug yep” and also note that is not on “older systems” in fact i had the problem with a new 2020 intel nuc, if you are curious is explained here why that happens

Appimage is cool but if you compile on a older system… if not for example one appimage created in ubuntu 20 will not run in 18 per GLIBCXX version as is mentioned here also.

@pandereto, Thanks for this info. I’ve just downloaded 0.11.1 and it seems it has the fix. I’ll try running the binary on other systems to see if it did the trick.

Yes, I’m compiling on 18.04, hoping it will work for this and future versions. The AppImages I tried were not working with debug flag but they did for release so it wasn’t the problem with the AppImage itself.

I’ll write you guys back if it works ! (it might take a while though)

The AppImage creators actually talk about how you should use the oldest glibc possible, in order to not break compatibility. Ubuntu-wise this would mean building against 16.04, but I think it’s reasonable to only use 18.04, especially since I’m not sure if the latest OF works on 16.04

Sure, in my case that is not possible because i have some dependecies that works only in 18-20.

I use this script i found somewhere to copy shared libs to appImage folder lib maybe is overkill as will copy all libs used in the app but…

Sure there is a more cool way to do that removing from the list libraries that are included in os installation… but my bash powers are not enough

 ldd YOURAPP | grep "=> /" | awk '{print $3}' | xargs -I '{}' cp -v '{}' PATH_TO_COPY_LIBS

Just fyi, the Github Actions CI uses 16.04:

Oh that’s great!! That really does make things look promising for a “universal” OF App Image. I’m going to have to spend some more time looking at this…

Don’t say it so hastily!
We all would want the AppImage be so universal across Linux distros as it claims to be, but the best test is to test it on as much linux distros as possible.
Boot up some Gnome Boxes or Oracle VirtualBox and give it multiple linux Live environments (download .iso files for each different linux distro) - you don’t even need to setup virtual harddrives, just get your built appImage on that live environment and try to run it via terminal. If it runs without errors (well, if it even does manage to run), great - this linux distro is checked off as success.

Constantly running into errors and issues with running my compiled ofApp, (built in Debian 10 Buster) turned into appImage despite following instructions by @macramole.

Testing on Virtual environments (booted Live cd images):

Debian 10 Buster (Fresh Live via VM without OF dependencies):

works natively (because it was built on the same version)

Manjaro 20.2.1:

 /tmp/.mount_myGUI-DrqHDS/AppRun: line 2:  1919 Segmentation fault      (core dumped) LD_LIBRARY_PATH="${APPDIR}/usr/lib:${LD_LIBRARY_PATH}" ${APPDIR}/usr/bin/myGUI

Fedora 32 KDE Spin:

*** stack smashing detected ***: <unknown> terminated
/tmp/.mount_myGUI-WiP6BQ/AppRun: line 2:  2039 Aborted                 (core dumped) LD_LIBRARY_PATH="${APPDIR}/usr/lib:${LD_LIBRARY_PATH}" ${APPDIR}/usr/bin/myGUI

Ubuntu 18.04 LTS Live:

*** stack smashing detected ***: <unknown> terminated
/tmp/.mount_myGUI-1v63bn/AppRun: line 2:  5338 Aborted                 (core dumped) LD_LIBRARY_PATH="${APPDIR}/usr/lib:${LD_LIBRARY_PATH}" ${APPDIR}/usr/bin/myGUI

OpenSUSE Leap 15.2 KDE Live:

*** stack smashing detected ***: <unknown> terminated
/tmp/.mount_myGUI-k3U1gB/AppRun: line 2:  2837 Aborted                 (core dumped) LD_LIBRARY_PATH="${APPDIR}/usr/lib:${LD_LIBRARY_PATH}" ${APPDIR}/usr/bin/myGUI

Oddly enough, I tested @macramole’s AudioStellar on some Ubuntu and Debian, even Fedora and Manjaro, and even though terminal yielded some errors it started at least.

However, the exception is openSUSE, which I guess has no OF support anyway (you won’t find install_dependencies script for this one for example)
And AudioStellar failed to run when tested on openSUSE

AudioStellar on OpenSUSE Live:

/tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar: /lib64/ version `GLIBC_2.27' not found (required by /tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar)
/tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar: /lib64/ version `GLIBC_2.27' not found (required by /tmp/.mount_AudioSWgWsAV/usr/lib/
/tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar: /lib64/ version `GLIBC_2.27' not found (required by /tmp/.mount_AudioSWgWsAV/usr/lib/
/tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar: /lib64/ version `GLIBC_2.27' not found (required by /tmp/.mount_AudioSWgWsAV/usr/lib/
/tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar: /lib64/ version `GLIBC_2.27' not found (required by /tmp/.mount_AudioSWgWsAV/usr/lib/
/tmp/.mount_AudioSWgWsAV/usr/bin/audiostellar: /lib64/ version `GLIBC_2.27' not found (required by /tmp/.mount_AudioSWgWsAV/usr/lib/

Frankly, I’m becoming more and more skeptical about “universality” of appImages.
What system does it take to make it an OF AppImage cross-distribution?

If we ask @theo, would you suggest making OF builds (that could be bundled into AppImage) in Ubuntu 16.04 to achieve maximum (even forward) compatibility? Shouldn’t Debian be even more compatible, being the parent to Ubuntu distro and all its spinoffs?

We might also consider thinking about alternatives like Snap, or Flatpak…
At least Flatpak, in comparison with Snap and AppImage is installed in the harddrive without interfering with system libraries (having them self-contained), as well as its data are not read-only like AppImage (or Snap, that uses squashFS on the app similar to AppImage, allegedly).

Im curious, did you test another appimage application like etcher, cura,…etc etc in those installs to see if is a problem of AppImage or a wrong implementation?

Thanks @mr.Bitmap for taking the time to test this. I don’t have the time or resources to test in that many distros.

I also don’t think the AppImage will work in all systems, but it is nice if it works at least in the major ones.

We tried building for Flatpak too and it did work but it was very slow. Probably there was more work to be done for getting a faster build, but since AppImage is (kinda) working we will keep on this track.

Too bad it doesn’t work for your app, I’m building my binary on Linux Mint based on Ubuntu 18.04, maybe you should try building on the same (or similar) system ? Also, maybe you are using some addon that requires additional libs ?

Gotta test it yet… If other free downloadable apps can be run everywhere, then there must be problem with OF dependencies + GLIBCC versions used…

Nope, no addons, no extensions, just pure OF. It seems it matters greatly which distro you build the app in. @theo mentions Ubuntu 16.04 with older GLIBCC version used in GitHub CI.
And if we look into download site of VirtualBox for Linux, they imply using EL6, being for “All distributions”, quoting: (built on EL6 and therefore not requiring recent system libraries)


Thanks for everything @macramole!!!
Your kindly AppImage example helps a lot, and I’ve finally found a way to make everything run. Now I know how you could even manage to run AudioStellar on openSUSE Leap 15.2 (which uses older GLIBC than 2.27 your app is tied to, currently, because of building on Ubuntu 18.04 based distro (when you enter the command ldd --version in your Linux Mint system you built that, you should see version 2.27))

I booted up Ubuntu 16.04 Xenial Xerus in VM (according to @theo’s great suggestion) , had to make adjustments to upgrade to GCC6 (not GLIBC, don’t confuse these two; GLIBC is tied to the OS and can’t be updated without ruining your system, that’s why you should never attempt to update it…) - so that you can install dependencies and compile new OF_v.11.1 on it.

There’s this essential issue you would never have imagined you need to do - When bundling your libraries from ldd into your .AppDir to make AppImage,
I use:

ldd YOURAPP | awk 'NF == 4 { system("cp " $3 " YOURCHOSENDIRECTORY") }'

to copy all the dependencies it needs so it doesn’t leverage it from the system (the OS doesn’t know it unless oF dependencies are installed).

BUT - there is also a list of .so libraries that must NEVER be included inside an AppImage -

And so I did checking & deleting from the copied .so libs one by one - those that I found on the list.
And guess what - after making: appimagetool myOFproject it worked on every Linux distro so far I tested: Linux Mint 19.1 Cinnamon,
Ubuntu 18.04 LTS,
Kubuntu 18.04,
Fedora 31 Workstation,
Fedora 32 KDE Spin,
OpenSUSE Leap 15.2


And both OpenMandrivaLx 4.2 and Manjaro 20.2.1 Nibbia Live (booted with both open source and proprietary drivers) ran ok, but it had some weird openGL issues - the display was rather darkened - maybe some additional drivers would fix it… (?)

The only warning for all except my current Debian 10 Buster and Fedora 31 Workstation in the terminal was: libEGL warning: DRI2: failed to authenticate,
but aside from that, it all runs fine.

Note that all these compatible distros have to have at least GLIBC version 2.23 (that’s what Ubuntu 16.04 has if you build in this) - understandably, it didn’t work for example on CentOS 7 (which has older GLIBC 2.17).

My previous errors of *** stack smashing *** of an AppImage were caused by bundled system libs inside. It is deleting those according to the list that made it run successfully - I had this very issue: (and according to @probonopd’s reply in the link, there’s also linuxdeployqt or others that should bundle automatically what it needs…)

So, to sum it up, for maximum compatibility, you need the oldest GLIBC version build possible. Here’s a brief list: under 2. Distribution Branch Mapping, where Branch column refers to GLIBC version of that particular distro.
I’m currently trying if I can make Debian 8 Jessie with GLIBC 2.19 compile OF, but before that, I have to upgrade to gcc6 from source, as it doesn’t have official repositories for that :astonished: .

The best optimal solution would be if we could get the newest oF to compile successfully on RHEL6 or CentOS 6 (as 5 might be a rather too outdated) - that would give us even older GLIBC 2.12 :slight_smile:
However, finding all the dependencies and installing gcc6 might be a real problem… If anyone would want to attempt this, it would be great news, but I’m wondering if all the drivers and dependencies can keep track on this old distro…


Wow, that is great news! @mr.Bitmap

One thing I should have also pointed you too is the setup script for the CI builds for 16.04.
The script below shows the steps we take for installing GCC6 on 16.04

1 Like

Thank you @theo.
Based on this, it seems Ubuntu 16.04 is kinda ‘native’ compatible for the oF.
This will be useful for all who would build on Ubuntu 16.04, yielding them GLIBC version 2.23 per each OF App.

Any chance you could maybe switch to CentOS 7 (free community-based Red Hat distro based on RHEL 7)?
That way the GLIBC version would be 2.17 (the lowest possible, while still maintained for following next 3 years - EOL 2024-06-30) for maximum Linux compatibility.
Dependencies would not be easily tracked from the beginning, but once they’re all found and accounted for, an example script for installing these for oF would help every oF developer greatly to make for the most possible compatible AppImages made in oF.

@mr.Bitmap I’m not sure trying to use a really old version of glibc is such a great idea. Ubuntu 16.04 is already quite old (it will no longer be supported by April 30, 2021). I suspect that you might run into other issues related to an ancient gblic too. CentOS is also on it’s way out. I understand what your suggesting, but it’ll probably just increase the workload, potentially cause problems and really only cater for a small select number of older distros.

Very happy that you got your AppImage working, when you posted earlier I was sure there was going to be a work around :slight_smile:

EDIT: For reference, I just did a quick search, and it seems Valve require glibc 2.19 (since about a year ago) as minimum requirement for their Steam app. I don’t think we want to go much older than that…

1 Like

I get your point, but there’s got to be a middle ground.
Older Linux distros outdated and not supported any longer? Maybe, but on the other hand, have you OF app built in any distro with newer GLIBC than your target customer distro, and there’s no way you’re getting the AppImage run on target distros…
There’s got to be a compromise, let’s say - ok, we need to build on a still supported distro, but with the lowest glibc possible, because there’s always forward compatibility regarding this, but never backward compatibility.

Are you sure Ubuntu 16.04’s support is going to end this year? In the following link the EOL is mentioned as 2024-04. But if Valve require glibc 2.19 it must mean (I’m positive that) they were using even older (glibc-wise) Debian 8 Jessie as a basis then, which came to its end in 2020-06-30 (check this: ).
And it makes sense, because as far I as recall, SteamOS is based on Debian.
I’ve seen it before on

If we would want glibc 2.19, we first need to get gcc6 running on Debian 8 Jessie, which I already attempted to do in VirtualBox in order to successfully compile OF. And that is by no means an easy task… :neutral_face:
The farthest I got was installing gcc6 from source but not in the system but as a separate folder within home folder. The system doesn’t recognize it yet as a gcc alternative when trying to
update-alternatives --config gcc

I basically agree with you, we should try and go back as far as we can, I just don’t think CentOS is terribly vital as a target. Ubuntu 16.04 works well enough.

I think it does EOL this year:

Just wanted to thank everyone involved in this thread, especially @mr.Bitmap whose most recent instructions were very useful.

My AppImage is here:

It took a while to get Gstreamer working (video capture and video playback) but it’s all working now. Still have some app icon issues, but I deal with that later.

I think this AppImage could be the basis for any OF AppImage, as I think it uses all the core stuff.


Great app !! Working fine on Linux Mint 20.1 . A tutorial would be nice :wink: but I could do a couple of things (loading a video and appling transformations)

About the icon on Linux, we solved it like this: src/main.cpp · units · ayrsd / audiostellar · GitLab

The only problem about this approach is setWindowIcon being private, but we sent a pull request a couple of weeks ago and I guess its going to change.


Ah yes I’ve used that icon method before, and had same issue with the private method.

Yes LPMT needs more documentation, and really, more work. If I get time I’ll revisit it.

The AppImage stiill doesn’t load videos on Manjaro (and therefore probably Arch too), but that’s just because of some missing libraries needed to get Gstreamer working happily. I will fix that soon. It should run happily on all Debian related distros though.