AppImage SSL issues

Quick question for @matterhorn103 - you mentioned that the AppImage has problems with HTTPS because it doesn’t have the right versions of OpenSSL libraries.

If you can remind me of the fix, I can adjust the build scripts (e.g., for 1.99) to grab the right libssl pieces.

The issue was that the AppImage (and I guess maybe some or all of the other builds?) are being built against OpenSSL 1.1, which many distros have deprecated and most ship with >= 3.0.

The solution is just to build Avogadro with OpenSSL 3 or newer.

The dirty fix for an end-user is to install OpenSSL 1.1, but that’s not possible on all systems.

The relevant issue is this one which also links to a discussion of the issue.

The AppImage doesn’t contain OpenSSL as it stands – it is one of the various libraries it sources from the system. As an aside, I believe this is an example of where AppImages are not quite self-contained in the way Flatpaks are.

I’ve just seen your question on the GitHub issue back from December, sorry. I’ve uploaded the full directory/file tree of the decompressed AppImage there. libssl is nowhere to be seen.

Ugh. That’s a bit of a pain, because it means we’d need to compile Qt from source and include all the Qt libraries with the AppImage.

Yeah, I think that’s the solution - to copy the OpenSSL 1.1 libraries into the AppImage.

I’ll look into that.

Before you reckoned that it’s impossible to choose which Ubuntu version is used for the AppImage build. Is this definitely true? Because building on 22.04 would solve the issue too, as it has the more modern OpenSSL.

AppImage generally wants the packages built on the previous LTS (e.g., 18.04 until 22.04 was released). So in April, we’ll be able to use 22.04.

I’ll ask if there’s a way to have both a 20.04 build (with OpenSSL 1.1.1) and a 22.04 build (with OpenSSL 3) because after spending ~15 minutes looking through the AppImage forum and issues, there’s no good answer.

Ok, I have done some digging on the origin of the restriction. Basically the answer is that it’s the arbitrary choice of one dev.

The AppImage documentation recommends building the binary on as old a Linux distribution as possible in order to have compatibility with as wide a range of distros as possible. However, this is not mandated by the spec and an AppImage can be prepared using any binary and any set of libraries on any distro; indeed, it’s sometimes recommended to prepare AppImages for multiple target distributions.

linuxdeployqt is what is being extremely opinionated here, and seeks to enforce the above recommendation by raising errors and refusing to run if “recent” distributions are used. “Recent” is currently defined by the developer as either the oldest still-supported LTS release of Ubuntu, or more specifically as a distro using a glibc no newer than 2.31.

We wouldn’t be the only people to complain about how limiting linuxdeployqt is. It has been pointed out that 20.04 isn’t even supported by Qt for Qt6 development.

Importantly, I’ve found there are ways round this.


As one possibility, we can run linuxdeployqt with the flags -unsupported-bundle-everything -unsupported-allow-new-glibc. This is explicitly unsupported, so the dev doesn’t want to hear from any issues while using it, but it apparently works just fine.


But the other thing is that we aren’t obliged to use linuxdeployqt, as it’s not even the only tool that can bundle Qt for an AppImage. There’d be other reasons to think abotut moving away too; the dev says he’s no longer working on the codebase. He focusses on go-appimage instead, which is also what he recommends if you need to use newer Ubuntu releases. The tool also explicitly doesn’t support Wayland (the dev says he has no desire to do anything towards this, even in 2023).

go-appimage is one option, but honestly doesn’t seem super established. There are two better options:

  1. appimage-builder, which takes a different approach; it bundles much more stuff with the AppImage by default, including glibc and SSL libraries, plays better with environment variables, etc. This would solve the SSL issue, and would allow building the Qt6 AppImage on 22.04. It has examples for Qt builds. But it would make the AppImage 30Mb larger (though I really don’t see Avogadro’s size as a problem, and people who do care are unlikely to use the AppImage anyway because it bundles Qt).

  2. linuxdeploy, which was actually envisaged as the successor to linuxdeployqt and seems to be the most established solution. The official AppImage documentation uses it in its packaging guide. It’s used by AppImageLauncher and appimaged.

linuxdeploy can work with an existing binary (i.e. as a drop-in replacement for linuxdeployqt) but it can also build from source in conjunction with cmake.

It has a plugin system, and there’s a list of plugins over at awesome-linuxdeploy. The Qt plugin explicitly supports Qt5 and Qt6! There’s even a plugin that bundles and sets up miniconda

Of course, the last option is to just assemble the AppImage manually, though this seems tedious.


One last thing – there’s also a project for AppImages with bundled Python.

1 Like

If I’m honest the main outcome of my research is that my enthusiasm for getting the Flatpak polished, fully functional, ready for Qt6, built as part of the GitHub Actions, and available as a nightly version has been redoubled. The format is far better and I’d love to get it rock solid by 2.0, so that (+ the docs) will be my focus from now till release.

Thanks - I hadn’t heard about linuxdeploy – we’ve had previous issues with linuxdeployqt. So I’m happy to try the unsupported options first.

It does seem like the AppImage is currently stripping debugging information (sigh)

So I’ll work to update the AppImage and hopefully that will fix the bug with crashes in chlorophyll… because it seems to work when run outside of the AppImage.

1 Like