Re: [Golly-test] Linux AppImages for Golly

[Dongook L. <sco...@gm...>]

Hello again, everyone, this is Dongook Lee (Scorbie on the
conwaylife.com forums).

0) Thank you
I would like to start with a big Thank You for the Golly Gang for
their commitment in maintaining the software. Especially maintaining
this as open source and cross-platform so that a Linux user could view
and tweak with its source. Also special thanks to Tom who gave me a
warm welcome and valuable feedback.

I am a regular user of Golly who happens to use Linux, and will try to
describe the situation as fully as possible. If you have any comments
to add, or wrong statements to fix, please feel free to reply.

(1) The Problem

Golly's Linux binary `golly` works in some Linux distributions, and
doesn't in others.

When it doesn't work, it shows a message in the following format.
```./golly: error while loading shared libraries: libpng12.so.0:
cannot open shared object file: No such file or directory```


(2) The Problem, elaborated
Golly's Linux binary `golly` depends on `libpng12.so.0`, which is a
DLL of libpng, version 1.2.xx. In Ubuntu 18.04 LTS, there's
`libpng16.so.0`, libpng version 1.6.xx, but not `libpng12.so.0`.
Because of this mismatch in shared library versions, the binary won't
run.
Apparently this is a known issue. Here's the relevant forum thread
that I mentioned earlier.
https://conwaylife.com/forums/viewtopic.php?f=4&t=3627
Different Linux distributions have different versions of shared
libraries, and the users (actually two) report different missing
shared libraries. As Andrew says in the forums, this difference in
shared library versions in various distributions makes it hard for the
Linux binary distributions to work reliably in multiple distributions.


(3) Possible solutions 1 - Prior art.
Recently there has been multiple independent projects to package Linux
binaries work in multiple Linux distributions.
There's "Snap", directed by Canonical, "Flatpak", that I thought was
directed by RedHat but seems to be a community project, and
"AppImage", a community project as far as I know.
As far as I understand, these work roughly similar to a
self-extracting executable; When packaging, the necessary shared
libraries are bundled inside the executable. When run, it extracts
itself, and then additionally executes the contents.
AppImage was the first thing to try, but I am eager to try any other
solutions if one wishes.
One caveat when building with AppImage: It is open-sourced, but it
recommends downloading a precompiled binary (in, surprise, AppImage
format) for packagers to package their app. I could try building it
from source, and use that for packaging, but the current builds are
done using those binaries.


(4) Possible solution 2. DIY packaging. - Warning: haven't tried seriously.
Looking at the build process, the AppImage seems to bundle the
necessary libraries and licenses, change the executable rpath and the
shared library rpath. Rpath seems to be the path hardcoded inside a
binary executable and used to find a shared library when an executable
is run. So we could bundle the necessary libraries within a Golly
Linux binary distribution, set rpath to point to there when building
Golly, and hopefully we'll have a working binary... in theory.

==========
Okay, that was the story, wanted the important parts to be at the top,
but I'm not sure if I did a good job. There are still some details
missing that I hope will be covered with further conversation.

Here's the gzipped source that I used to package the app, so that
maintainers could freely audit it. - DISCLAIMER: this uses a
precompiled binary from an AppImage maintainer. And I couldn't find an
Ubuntu package for it. Run it only if you trust the binary.

[To package on one's machine]
(1) Prerequisites: apt-get install fuse wget libglu1 libSM6
libgtk2.0-0 imagemagick
(2) run `VERSION=3.3 PLATFORM=x86_64 ./build.sh` (for 32bit use PLATFORM=i386)
[To package with docker]
(1) run `VERSION=3.3 DIST=ubuntu PLATFORM=x86_64 ./build.sh` and it
will grab Dockerfile-ubuntu-x86_64, set it up, and build it for you.

Or at least that's how it's intended to be used.
I'll work into merging this (or other scripts) into a makefile-gtk, if
this anyhow gets useful.

Again, thank you for your time. Hope this becomes useful, in any way...

---
Best wishes to you,
Dongook Lee (Scorbie)