It’s been a long day and I’m probably not in the best state of mind to be asking this question, but have you guys solved packaging yet?
I want to ship an executable with supporting files in a compressed archive, much like the Windows exe-in-a-zip pattern. I can cross-compile a Win32 C program using MinGW that will always use baseline Win32 functionality, but if I try to build for Linux I run into the whole dependency versioning situation, specifically glibc fixing its symbol version to whichever Linux I happen to be building from at the time. But if I try to static link with musl, the expectation is that everything is static linked, including system libraries that really shouldn’t be.
AppImage is in the ballpark of what I’m looking for, and I’ve heard that Zig works as a compatibility-enhancing frontend if you’re compiling C. I’d just like something simple that runs 99% of the time for non-technical end users and isn’t bloated with dependencies I can’t keep track of. (No containers.) Is this easily achievable?
I think you are confusing “windows like” with “user-friendly”. A “bespoke archive, that you find on some developer’s website, that you extract and somewhere it contains an executable and assets, that you move where you want to keep them, and then the user remembers to manually update it sometimes somehow” is not how you usually do stuff on Linux and is not even user-friendly.
Distributions come with programs like “gnome software” or “kde discover” that allows the user to graphically install programs from the distro’s package manager, or from flatpak or snap. It will also help them to keep them updated and to manage dependencies. That is user-friendly.
I suggest using flatpak. It will work on almost all distros out of the box and will be easy to install and maintain for the user. If flatpak is too “bloated” for you because it uses containers, then you need to package it for every distro manually, but that’s a lot of work. If it’s something that just needs to be used once and never again, consider an appimage or a script, because they don’t need to be installed.
Distros are different operating systems, it’s not gonna be easy to package for all of them without compromises.
Also, if you really really really need to use your bespoke archive, you can do like native steam games do, and put every library you link in the archive, and link with relative paths instead of system wide paths, or with a launch script that loads your provided libraries. But that’s not a great user experience. Steam gets away with it because it’s the launcher that manages the whole thing.
Glibc preserves backward compatibility, so if you build against the oldest version you want to support, the resulting binary will work with newer ones.
However that’s definitely not what I recommend to do. Better learn packaging and build native packages for distros you are going to support. OBS can make this a bit easier (if your software is FOSS), but any modern CI will also do the job.
A solution I’ve used for the glibc problem, is to build on an older distribution in a chroot. There is also this project which might be of use to pick a specific version of glibc. The project README also explain how to do it manually.
As for distribution, I prefer something like makeself.sh, that installs to either ~/.local/ or if it is to be installed system-wide to /usr/local or /opt. The concept is just a small shell script appended with a compressed archive, it is easy to modify and even create by hand using standard tools like cat. This is a method widely used by native Linux games.
I’ve built a Dockerfile that does a hybrid of solution 1 and AppImage building.
It compiles the software with an older Debian release, then packages the software in a Python AppImage with necessary dependencies installed and the proper dynamic libs copied.
Using containers for build environments is probably my favorite use of containers.
I have an application I build for Linux, Mac and Windows and frankly building two or three Linux builds in containers is easier than the Windows and Mac builds alone. A github action automates it easily.
At $DAYJOB, we’re currently using this to cross-compile a C/C++ application: https://github.com/dockcross/dockcross
If you just want x86-64 with old glibc, you can use their “manylinux” image.
But yes, this does not solve C applications being a massive pain in the ass to distribute, so you may still want to ship it as an AppImage or container image or with static linking or whatever.
