Setup AppImage builds for Linux

[ghost]

OS: Debian 9.x (x86_64)
Version: http://strlen.com/treesheets/treesheets_linux64.tar.gz

I just try to use portable build but it failed:

$ ./treesheets
./treesheets: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by ./treesheets)

[aardappel]

I haven't updated this binary in forever.. I assume people build from source or get it from their package manager. I can update it and see what changes.

[ghost]

I can update it and see what changes.

Please, lets build AppImage-package automatically (using Travis CI) instead!

1. https://github.com/appimage/AppImageKit
   1.1. https://github.com/probonopd/linuxdeployqt OR https://github.com/linuxdeploy
   1.2. https://github.com/probonopd/uploadtool

For any help ask @probonopd @TheAssassin

[aardappel]

If you want to add such changes to Travis, that be welcome.

[ghost]

If you want to add such changes to Travis

Does treesheets could be compiled under Trusty (Ubuntu 14.04) or Xenial (Ubuntu 16.04) is minimal requirements?

[aardappel]

Not sure, not that familiar with Ubuntu releases. It requires C++17 nowadays, which means a newer Clang/GCC, so that will likely be your limiting factor.

[TheAssassin]

GCC 7 seems to support C++17 mostly, there's just one minor feature that'd require GCC 8. See https://gcc.gnu.org/projects/cxx-status.html.

Ubuntu 18.04 (bionic) ships with GCC 7.4 by default, so I'd suggest to build off of that, unless some older release is also viable. Not ideal, but good enough to get started. You won't have any better compatibility by building on older distros with newer compilers anyway. And you don't have to install any extra packages.

Looking at the Travis file, right now it's using the EOL trusty with some Ubuntu PPAs to get some GCC 7. Since trusty is EOL, libraries etc. won't receive fixes, so if possible I'd try to upgrade to xenial or bionic.

Either way; as long as you get your project built, it can be easily AppImage-ified. A guide is available at https://docs.appimage.org/packaging-guide/from-source/native-binaries.html, there's ready-to-customize scripts at the bottom of the page.

[ghost]

I'd try to upgrade to xenial or bionic

If so, would resulted AppImage still runnable on Debian 9.x Stretch?

[TheAssassin]

Well, none of these platforms have a recent enough libstdc++ to support C++17, have they? Therefore, no, rather unlike.

[aardappel]

Note that the current travis file pulls in newer gcc/clang manually, so it may well be possible to upgrade the dist without doing much else.

[probonopd]

`GLIBC_2.27' not found

That version is from 2018. Hence this binary will not run on older distributions. To make it run on older distributions, compile it on a system with a (much) older glibc. https://www.gnu.org/software/libc/ has a timetable.

[aardappel]

Ok, so recompiling on my current system doesn't work. I don't have an older Linux available, but I suppose I could make a VM for that purpose..

Then again, how does anyone release software this way? I guess I am not following what is the standard way to do this on Linux.

[TheAssassin]

An option is to use https://github.com/probonopd/uploadtool to auto-deploy built binaries to GitHub releases on every build.

[probonopd]

Ok, so recompiling on my current system doesn't work. I don't have an older Linux available, but I suppose I could make a VM for that purpose..

Compiling on a local developer machine is not the recommended best practice anyway. Have you checked out systems such as Travis CI? This way, you won't need a virtual machine on your local system. Example: https://github.com/probonopd/linuxdeployqt#using-linuxdeployqt-with-travis-ci

Then again, how does anyone release software this way? I guess I am not following what is the standard way to do this on Linux.

No. The "standard way to do this on Linux" before AppImage has been to dump the source code somewhere, pray and wait that some Debian developer picks it up and packages it, so that it eventually lands in the Linux distribution at some point. And then rinse and repeat for every other Linux distribution. Only to find out that once the software is in Debian stable, it is long outdated...

[aardappel]

so that it eventually lands in the Linux distribution at some point

That's not very practical for the long tail of less popular software, or early in development. And creates an enormous lag between software improvements and users getting them. I don't understand why people think this is a workable system.

But anyway, agree that making CI do it is the modern way to help with this. This project already uses Travis. I just don't have time right now to investigate how to make it do all this new functionality, so if someone feels like tinkering with it, PRs much appreciated.

[ghost]

That's not very practical for the long tail of less popular software, or early in development.

This exactly a reason why such software should be AppImage'd

Because not popular software often ignored by package maintainers.

[probonopd]

That's not very practical for the long tail of less popular software, or early in development. And creates an enormous lag between software improvements and users getting them. I don't understand why people think this is a workable system.

Precisely. I was just describing the "standard way to do this on Linux", and I agree it is not very useful for the long tail of software, and for software that is under heavy development.

Hence, AppImage :-)

[aardappel]

Fair enough. So who can add AppImage support to the .travis ?

[probonopd]

Yes. See https://github.com/probonopd/linuxdeployqt#using-linuxdeployqt-with-travis-ci for an example,

[aardappel]

For what its worth, the 64-bit binary on http://strlen.com/treesheets/ has been updated to today (sept 2 2019), built on Mint 19.1

[probonopd]

Thanks @aardappel but I don't see an AppImage being mentioned there?

[probonopd]

Related: #108

[probonopd]

I am trying to generate an AppImage but I am running into this issue:
#133

Here is my work-in-progress .travis.yml:
https://github.com/probonopd/treesheets/blob/patch-1/.travis.yml

[aardappel]

@probonopd that was just FYI, for whoever in this thread just wanted a new binary.

As for an AppImage, try build with CMake.

[probonopd]

As for an AppImage, try build with CMake.

Which is what I am doing:
https://github.com/probonopd/treesheets/blob/14ac890efadf52c611b1b95604ec1089606869a7/.travis.yml#L86

[aardappel]

Not sure what CMAKE_INSTALL_PREFIX is going to do, but my guess is it won't work. The TreeSheets binary should be placed in the TS dir (which it does by default I think), since it needs the files in that dir at runtime, and addresses them relative to the executable location. So then everything in the TS dir needs to be packaged into the AppImage.

[probonopd]

I am working on a workaround now, let's see how it goes.

[probonopd]

I was able to build "something" but I can't test it right now, so it would be great if someone could, and report back what is working and what is not working yet. Thanks!

https://github.com/probonopd/treesheets/releases/tag/continuous

[probonopd]

Oopsie! Something is not working well yet:

me@host:~$ Downloads/TreeSheets-73fa476-x86_64.AppImage 
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.8).
Aborted

Any clue what might be going on here?

[Vaelatern]

Change in the C++ ABI it looks like.

[TheAssassin]

If it works on xenial and newer, it can pass the tests... give me a second.

Well, it's up to @aardappel whether to merge weird workarounds that are guaranteed to break in the future.

But I think using AppRun.c may fix this.

Argh. Please don't. If it's just necessary to work around some weird resource lookup, then I'd like to ask @aardappel to read https://docs.appimage.org/reference/best-practices.html#binaries-must-not-use-compiled-in-absolute-paths (the section needs some improvements, as it doesn't explain all scenarios which might be fixed by looking up resources relative to the main binary, e.g., like here, where additional resources are likely just looked up relative to the install prefix and as a fallback cwd; looking up relative to the main binary should be on top of the list).

[aardappel]

That link says: For example, if the application accesses a resource such as an image, it should do so from a location relative to the main executable. which is exactly what I am doing (relative to whatever is in argv[0]).

[TheAssassin]

I see, thanks for the clarification.

Using argv[0] doesn't cut it then, I guess. The AppImage runtime uses execv() to run apps once the initialization is done.

In some other apps I always had to readlink /proc/self/exe to get the correct path. I think we need a MWE to check whether using argv[0] is viable. Let me quickly hack something together.

[TheAssassin]

Built a MWE for testing.

#include <stdio.h>

int main(int argc, char** argv) {
    printf("%s\n", argv[0]);
    return 0;
}

test-x86_64.AppImage.zip

Output:

> ./test-x86_64.AppImage 
/tmp/test-x86_64.AppImage

Making apps relocatable can be hard, mkay...

[aardappel]

TreeSheets strips away what it thinks is the exe name to obtain the path, so it will be looking for its files in /tmp then.

How is this supposed to work? Using argv[0] as the exe path is an age old practice that I'm sure lurks in a lot of code :)

I'd be happy to get the exe path in some other way for Linux.

[probonopd]

@probonopd hah, you did all this AppImage work before even trying the program itself? :)

Yes. All apps I ever run are AppImages at this point.

I'd be happy to get the exe path in some other way for Linux.

https://github.com/limbahq/binreloc might be an option. But before we cause additional work, did you try out https://github.com/probonopd/treesheets/releases/tag/continuous? 214fbf9 is working for me. I am now simply using a tiny bash script there:

#!/bin/bash
HERE="$(dirname "$(readlink -f "${0}")")"
exec "${HERE}/usr/bin/treesheets" "$@"

Does the trick.

[TheAssassin]

Either that, or, as I wrote, you can just read the real path of /proc/self/exe to get your own binary's path, e.g., using realpath() or readlink() (C functions).

[aardappel]

Yeah, don't think I want to pull in some non-standard library to get the job done. I'll try using readlink.

Haven't tried the AppImage build, I don't use AppImage personally (yet).

[probonopd]

Haven't tried the AppImage build, I don't use AppImage personally (yet).

Can you please give it a try so that we know whether everything is in a state that is OK for you to send a pull request? Thank you very much.

[aardappel]

If TreeSheets loads up with the tutorial file as first thing, it is working.

What I can't judge is the possible distro incompatibilities discussed above.

[probonopd]

@Symbian9 does it work for you? Is it ready for a pr?

[ghost]

does it work for you?

@probonopd, I just launched your build ;-)

I not yet tried do nothing and closed manually this app first session; here is this session full terminal log:

mypc@mx:~/Downloads
$ ./TreeSheets-214fbf9-x86_64.AppImage
w
08:11:12 PM: wxWidgets 3.0.0
l
08:11:12 PM: locale: en_US.UTF-8
c
08:11:12 PM: content scale: 1.000000
c
08:11:13 PM: Error: can't open file '/usr/share/treesheets/examples/tutorial.cts' (error 2: No such file or directory)
c
08:11:13 PM: Error: can't open file '/var/tmp/.mount_TreeShA02IJH/usr/bin/examples/tutorial-en.cts' (error 2: No such file or directory)
mypc@mx:~/Downloads
$

[probonopd]

PR sent: #134

PLEASE NOTE: For this to work, you need to set up GITHUB_TOKEN in Travis CI for this to work; please see https://github.com/probonopd/uploadtool.

[aardappel]

Ok, PR merged (and env var set beforehand).. lets see what happens.

[aardappel]

Just added code to get the exe path from /proc/self/exe: d0b4b60

Does this mean the script can possibly be simplified?

[probonopd]

Yes, in this case we don't need the AppRun script. I have sent a PR.

[probonopd]

Now, this is kinda strange...

AppRun: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /run/firejail/appimage/.appimage-9018/AppRun)

Why does it need such a new libstdc++.so.6?

[TheAssassin]

Well, @aardappel already explained the software uses C++17 features. Why shouldn't it require a recent enough libstdc++? It needs to be capable of C++17, which, as the name suggests, was released around 2017.

This again showcases perfectly that hacks like yours just cannot work. They might seem to, but after all, they're bad hacks and the testing is likely incomplete.

[probonopd]

Argh. "Modern C++" strikes again. Gotta bundle a private copy of libstdc++.so.6 then.

Everything gets rigorously tested in https://github.com/AppImage/appimage.github.io :-)

[probonopd]

PR sent: #136