Sorry for my late reply!
I’ve spent a good chunk of time the day before last working on the similar problem for MacOS, and we’ve seen similar problems on Linux before.
Our AppImage actually contains its own copy of OpenSSL, and from your error, I’m not sure how it ever worked. The error message your showing indicates that our software loaded the libssl.so.1.0.0 that’s included in the AppImage, not the copy that’s installed on your system.
After my most recent experience with packaging OpenSSL on MacOS, I think the right solution is for us to statically link the library. I don’t think this will make it into the next release, which has a huge set of changes already, but it shouldn’t be long after that.
We’re not doing much with OpenSSL, and I think statically linking it will fix a long tail of problems like this for our Linux and MacOS users. Especially on MacOS, which ships with an ancient version of OpenSSL.
Alphas 1-5 are an unusual build, since they actually add the new software backend (called graph-io) to the existing Logic binary, which is then packaged into an AppImage.
The next build completely drops the old Logic codebase and binary. It also uses Electron instead of requiring the user to have Chrome installed. It also uses Electron for packaging, so instead of an AppImage, we’ll release a deb and rpm package. This packaging system will not include a copy of OpenSSL.
Now that I’m thinking about it, we’ll still need a solution for libstdc++. we use a version if libstdc++ that’s pretty new, and not stock on most distros.
With AppImage, there was a handy feature to ship with a newer copy of libstdc++, but only actually use it if it’s newer than the user’s copy. With a deb package, it’s slightly more of a hassle for the user. It should be very easy for customers to install libstdc++ if required, I think using this convention:
sudo dpkg -i /path/to/deb/file
sudo apt-get install -f
This is because we’re compiling with gcc 7 and using C++17 library features.