Linux

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.

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.

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.

Maybe I'm missing something but this seems like a chicken egg problem. It seems like you are trying to approach this from a Windows perspective when you should approach it from a Linux perspective.

What's your end goal?

I quite enjoy Nix flakes for this. Only certain languages have good support though (C, Rust, Haskell, OCaml, ...).

I'm curious why you would think that containers are bloat? They require virtually no resources and are built into the kernel. A container is literally just a flag that you add when you exec on an executable binary.

flatpak