That's an ergonomic deficiency. In practice, you probably need more than glibc, so then you have to make sure that other bits are available in this chroot. And if it so happens that one of the build tools that you rely on needs a newer version of glibc than the one you're building against, it still breaks down.
On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform.
Do you build software on your desktop machine and ship it? Do you not build in a chroot (or container, how the cool kids call them nowadays) to make sure the build is actually using what you think it should be using?
You have to build in a chroot or similar in any case. Just use the CORRECT one.
> On Windows, you specify the target version of the platform when building, and you get a binary that is guaranteed to load on that platform.
Except if you need a c++ redistributable… then you must ship the redistributable .exe setup inside your setup because windows. Let's not pretend shipping software on windows is easier.
Anyway all of this only applies to proprietary software. For free sotware the distribution figures it all out, does automatic rebuilds if needed and so on.
Really, just stick to free software, it's much easier.
You don't need chroot to make sure that your build uses correct versions of all dependencies; you just need a sane build system that doesn't grab system-wide headers and libs. Setting up chroot is way overkill for this purpose; it's not something that should even require root.
In case of Windows SDK, each version ships headers that are compatible going all the way back to Win9x, and you use #defines to select the subset that corresponds to the OS you're targeting.
With respect to the C runtime, Windows has been shipping its equivalent of glibc as a builtin OS component for 7 years now. And prior to that, you could always statically link.
It works with future versions, not with past versions.