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.
If you want something simple most people can run, use flatpak. AppImage often fails for me because I’m missing some file.so
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.
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.
Thanks for the info! If I’m doing container builds anyways, this looks tasty.
I quite enjoy Nix flakes for this. Only certain languages have good support though (C, Rust, Haskell, OCaml, …).
deleted by creator
