It's not as simple as "windows programs include their dependencies". Windows has far better forward and backward compatibility than Linux (by which I mean Linux plus the required userland stuff - libc, ld, etc.)
That's kind of to be expected. Comparability is tons of extra effort that open source can't really prioritise, but don't just pretend that it is as good as Windows.
This is where autotools helps: ./configure --static. There are also equivalents for CMake.
Aside from that I also statically compile Golang programs all the time (specifically runc which is a container runtime that uses cgo and a bunch of other magic). If static compilation didn't work, neither would our releases.
Just because Rust only lets you statically link binaries if you use musl doesn't mean that nobody else knows how to link things statically.
> because glibc cannot be statically linked
This is patently false. It is true that glibc will make static linking _hard_ but it's definitely not impossible. You need to set some magic settings (that autotools does for you) which disables all of the dynamic loading stuff glibc does.
> It's not as simple as "windows programs include their dependencies".
But it is. If you ignore the core system libraries, and included all of the other library dependencies with programs, most of these problems would be fixed.
> Windows has far better forward and backward compatibility than Linux
glibc has symbol versioning so in principle (I have had to use this once or twice) you can use an older program (linked against an old glibc) on a newer glibc.
The issue is the dynamic libraries (which are handled by distributions in different ways). Try statically compiling a binary like that and you'll find that it will work between distributions and kernel versions.
> Try the same with some Windows apps and compare and contrast.
Because they include their dynamic libraries with their programs, which has its own tradeoffs (updating security issues in shared libraries is much harder, even if you had a package manager on windows -- which you don't).
> It's all the auxiliary libraries, much larger surface area.
Right, but GP's point was that Linux doesn't have userland-to-kernel stability and I was saying that's simply not true. It's true that there is no stable upstream driver API but there are also solutions to that problem as well.