Latest continuous linuxdeployqt build does not work on Ubuntu 16.04 LTS and openSUSE Leap 15.0

[MrMontag]

If I run ./linuxdeployqt-continuous-x86_64.AppImage --version on m Ubuntu 16.04 LTS or openSUSE Leap 15.0 the following error is written.

linuxdeployqt 5 (commit fc64c50), build 609 built on 2019-01-06 03:55:18 UTC
Please run on a system no newer than the oldest still-supported Ubuntu LTS release.
This is so that the resulting bundle can run on all still-supported releases of Ubuntu.

Two weeks ago the continuous build worked well on both machines. There are no issues with the latest release linuxdeployqt-5-x86_64.AppImage.

Is this behaviour intended?

[tkashkin]

Yes, this seems to be added in b9b57e2.

@probonopd I understand that you want to maximize compatibility with older distros, but please add an option to override this behavior.
I want to provide an AppImage of my app built on 18.04. I don't want to support ancient distros like 14.04 and I expect users to have a recent enough distro to run my app.

[TheAssassin]

These kinds of annoyances don't exist in linuxdeploy for a reason...

[probonopd]

Is this behaviour intended?

Yes, it is intended. The reasons are given in https://docs.appimage.org/introduction/concepts.html#build-on-old-systems-run-on-newer-systems:

It is considered best practice to develop and compile the application on the oldest still-supported Linux distribution that we can assume users to still use. For example, the oldest still-supported LTS release of Ubuntu is a good choice to develop applications against and build applications on.
(...)

I consider it good practice and want to encourage developers to develop against, and build for, the oldest still supported distributions. Mozilla, LibreOffice and many other great application projects do this. Personally I consider it "lazy" by an app developer to just develop for the latest and greatest distribution and tell users to "just upgrade your OS in order to use this application".

Also, I don't have the capacity to test and support linuxdeployqt on all kinds of distributions.

Which glibc version does Leap 15 come with? I am willing to discuss which glibc version should be the newest that we support.

[probonopd]

please add an option to override this behavior

I think the right thing to do in cases like the one you are describing would be to bundle everything, so that the resulting AppImage would still run on all still-supported distributions. I did not have the time nor priority to implement this, since the kinds of applications we are targeting with linuxdeployqt understand that they should not use more recent build systems than the oldest still-supported release.

I am open to adding options, as long as it is very clear that those options are neither recommended nor supported by me. As such, I would welcome pull requests that implement the following:

• -unsupported-bundle-everything: Bundles ALL dependency libraries, down to and including the ld-linux.so loader and glibc. This will allow applications built on newer systems to run on older target systems, but it is not recommended since it leads to bundles that are larger than necessary
• -unsupported-allow-new-glibc: Allows linuxdeployqt to run on distributions newer than the oldest still-supported Ubuntu LTS release. This will result in AppImages that will not run on all still-supported distributions, and is neither recommended nor tested or supported

[BumblingCoder]

This should be at most a warning. It is perfectly useful to bundle up the dependencies to be able to run executables only on systems newer than the oldest ubuntu. This can be due to customers being on rhel/suse/etc. or simply because the payoff from rebuilding the world for the few users who refuse to use remotely recent distributions isn't worth it. Making the tool not work at all on anything but 14.04 simply means that people will stick with version 5 of linuxdeployqt forever or move to other less hostile tools.

[dagheyman]

This broke our builds, (building on xenial), I think this should be a warning as well. Will revert to older linuxdeployqt in the short term, Ubuntu Trusty is EOL in 4 months.

[MrMontag]

linuxdeployqt is a development tool. It should be usable across many distros and it should support different project needs. So if a project wants to be as compatible as possible then it shall go for a build chain that allows that, but projects which do not have that requirement shall have the option to still use linuxdeployqt on their newer systems.

@probonopd openSUSE Leap 15.0 uses glibc 2.26.

[probonopd]

This should be at most a warning. It is perfectly useful to bundle up the dependencies to be able to run executables only on systems newer than the oldest ubuntu. This can be due to customers being on rhel/suse/etc. or simply because the payoff from rebuilding the world for the few users who refuse to use remotely recent distributions isn't worth it.

As said above, we want to encourage application developers to adopt a mindset that applications should be developed for the oldest still-supported (rather than the newest) distribution versions, so that the resulting binaries will work on all still-supported distribution releases. This is basic "platform thinking" and the way how backward compatibility works, on virtually any platform. Of course there may be legitimate situations in which it is not possible or desirable for an application to support all still-supported distribution releases, but those should really be the rare exception (e.g., for corporate deployments) than the rule.

What I want to avoid is "careless" developers to inadvertently just build against whatever distribution release they happen to be running on their development machine out of convenience, not caring about users of other distribution releases. Because those are usually the same types of developers who will be surprised when their shiny new AppImage fails the automated tests for https://appimage.github.io, creating additional work to backport, re-build and re-test the AppImage that would have been avoidable if the application had been developed for and built on an older distribution release to begin with.

For the rare exception cases, I would be willing to incorporate -unsupported-bundle-everything and -unsupported-allow-new-glibc options as mentioned above, if someone cares enough to send a PR. Again, my point is not to prevent anyone from doing anything, but to increase awareness that it is really a bad idea to build on bleeding edge build systems, because the resulting binaries will fail on some still-supported distributions, and will fail the tests for https://appimage.github.io/.

Making the tool not work at all on anything but 14.04 simply means that people will stick with version 5 of linuxdeployqt forever or move to other less hostile tools.

This is a misunderstanding, and I have clarified the wording of the message. linuxdeployqt will run on systems that have no newer glibc version than what the oldest still-supported mainstream distribution (currently: Ubuntu 14.04) ships with. It is not limited to Ubuntu or any particular Ubuntu release; all we want to avoid is people using it on "too new" build systems (no matter which distribution).

Once 14.04 is no longer supported as a distribution release, we may increase the "allowable" glibc version. It's only one quarter left until then...

[probonopd]

This can be due to customers being on rhel/suse/etc.

Clarification: I realize that the original message may have been misleading, hence I changed it. This is not about the brand of the distribution, this is simply about using an "old enough" distribution version (no matter what the brand) so that the resulting binaries will work on more than just the very latest distribution releases.

[BumblingCoder]

The bug isn't that it said to use Ubuntu, the bug is that it refuses to work at all. Should it be an error if I attempt to deploy from my development machine to another machine I control for testing? Should it be an error if I run the build script (which builds, packages, and tests) locally? Should it be an error to build on the distribution that I know all of the users on my software are using? I would say that these are all very valid scenarios, but they are all currently disallowed by the tool.

[Optiligence]

I wouldn’t call breaking stuff »encouragement«…
Our build is tested on the systems it has to work on.
We use this tool to ease dependency collection.
It would be appreciated if it remained usable as that.

[mhoeher]

I understand your point about making developers aware about the requirements against the platform they build on, which is I guess okay. However, being that restrictive and even breaking builds is IMAO going in the wrong direction, in particular for apps built on top of Qt - which this tool is supposed to bundle, right ;-)

Up to now, I used the pre-build Qt binaries from here: https://launchpad.net/~beineri

As you can see, recent Qt versions are no longer provided for Trusty. Because I want to use ideally the same Qt version for all target OSes for my apps, I had to upgrade to Xenial for the build. Which worked quite fine. Sure, the resulting AppImage might not have run on Trusty and comparable installations, but honestly, about which percentage of users are we talking here?

I really think that a warning would be sufficient, or at least providing a switch to ignore the error.