treesheets
treesheets copied to clipboard
aardappel
Setup AppImage builds for Linux
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)
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.
I can update it and see what changes.
Please, lets build AppImage-package automatically (using Travis CI) instead!
- 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
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?
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.
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.
I'd try to upgrade to xenial or bionic
If so, would resulted AppImage still runnable on Debian 9.x Stretch?
Well, none of these platforms have a recent enough libstdc++ to support C++17, have they? Therefore, no, rather unlike.
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.
`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.
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.
An option is to use https://github.com/probonopd/uploadtool to auto-deploy built binaries to GitHub releases on every build.
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...
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.
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.
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 :-)
Yes. See https://github.com/probonopd/linuxdeployqt#using-linuxdeployqt-with-travis-ci for an example,
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
I am trying to generate an AppImage but I am running into this issue: https://github.com/aardappel/treesheets/issues/133
Here is my work-in-progress .travis.yml:
https://github.com/probonopd/treesheets/blob/patch-1/.travis.yml
@probonopd that was just FYI, for whoever in this thread just wanted a new binary.
As for an AppImage, try build with CMake.
As for an AppImage, try build with CMake.
Which is what I am doing: https://github.com/probonopd/treesheets/blob/14ac890efadf52c611b1b95604ec1089606869a7/.travis.yml#L86
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.
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
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?
I think we need to compile with the exact same compiler that was used to build the Wx libraries, the one that comes with the distribution by default. Not a newer one.
So this may be at fault:
https://github.com/aardappel/treesheets/blob/3e61414d9bdf3b01a97f45b08a1afe117a0d13a1/.travis.yml#L48
Can we do without this?
@probonopd I already explained earlier that this software requires Ubuntu bionic, if the system native compiler shall be used.
Then either
- Change this software so that it can be compiled using the stock compiler in the oldest still-supported Ubuntu LTS release, which is xenial at this point (preferred)
- Also build the Wx stuff from source (overhead but likely doable - It is already being done for macOS!), or
- Forget about making an AppImage until bionic is the oldest still-supported release of Ubuntu
I'm afraid the TreeSheets code relies on C++17 features in ways that are not trivial to undo (building it without its scripting system), so if the stock compiler can't handle that, then building Wx from scratch is the best option.
Or
- We patch away the stupid check (it works, I just checked).
sed -i -e 's|1011|1002|g' appdir/usr/bin/treesheets. @TheAssassin is not gonna like it but it does the trick for me beautifully.
That won't solve the issue. Then libc wise the ABI issues will be gone, but you'd have to bundle libstdc++ then to make things work on other systems.
I disagree with @probonopd; I believe AppImages built on bionic are "good enough". The vast majority of all AppImage users will be able to use the AppImage, only a few people might be running into issues. That, however, won't be a problem for this specific software, since there hasn't been anyone complaining about the use of C++17 before it's somewhat safe to assume this won't happen.
See also https://github.com/aardappel/treesheets/issues/130#issuecomment-523057825.
Regarding:
We patch away the stupid check (it works, I just checked). sed -i -e 's|1011|1002|g' appdir/usr/bin/treesheets. @TheAssassin is not gonna like it but it does the trick for me beautifully.
That won't make it work on older systems either. I'm pretty sure you just tried that on some random OS. Try on the build OS. It'll crash.
If it works on xenial and newer, it can pass the tests... give me a second.
I believe AppImages built on bionic are "good enough".
As you know, they will not run on all still-supported releases of Ubuntu. As such they will not pass the test and cannot be listed.
Almost there... now it wants to load resources from where the AppImage is, not from inside the AppImage...
me@host:~/squashfs-root$ /home/me/Downloads/TreeSheets-4634caa-x86_64.AppImage
w
10:42:41 PM: wxWidgets 3.0.0
l
10:42:41 PM: locale: en_US.UTF-8
c
10:42:41 PM: content scale: 1.000000
c
10:42:41 PM: Error: can't open file '/home/me/Downloads/images/icon16.png' (error 2: No such file or directory)
F
10:42:41 PM: Error: Failed to load image from file "/home/me/Downloads/images/icon16.png".
c
10:42:41 PM: Error: can't open file '/home/me/Downloads/images/icon32.png' (error 2: No such file or directory)
F
10:42:41 PM: Error: Failed to load image from file "/home/me/Downloads/images/icon32.png".
But I think using AppRun.c may fix this.
Please try https://github.com/probonopd/treesheets/releases/tag/continuous again now.
Played with it for one minute and already liking it very much. :+1: I wish Excel could learn this neat trick!
I wish Excel could learn this neat trick!
I wish LibreOffice Calc could learn this neat trick too!
@probonopd hah, you did all this AppImage work before even trying the program itself? :)
you did all this AppImage work before even trying the program itself? :)
Yeah, for trying any software, that not distributed in binary form (yet) for your Linux distro, user should compile it from source firstly ;)
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).
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]).
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.
Built a MWE for testing.
#include <stdio.h>
int main(int argc, char** argv) {
printf("%s\n", argv[0]);
return 0;
}
Output:
> ./test-x86_64.AppImage
/tmp/test-x86_64.AppImage
Making apps relocatable can be hard, mkay...
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 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.
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).
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).
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.
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.
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
$
PR sent: https://github.com/aardappel/treesheets/pull/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.
Just added code to get the exe path from /proc/self/exe: https://github.com/aardappel/treesheets/commit/d0b4b60c270f73397ddf75ccb7759ec8d6b94765
Does this mean the script can possibly be simplified?
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?
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.
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 :-)