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.
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.