Just like with Windows the challenges affect developers rather than users.
> You get a new Glibc, old binaries still work, it's fine.
Indeed, but when you need to build for an older glibc it's not so simple. This is a common use case, since e.g. AWS's environments are on glibc 2.26.
Ideally you'd like to build for all targets, including older systems, from a single, modern environment (this is trivial in Windows) -- and you can do some gymnastics to make that happen[1] -- but in practice it's easier to just manage different build environments for different targets. This is partly why building Linux wheels is so convoluted for Python[2].
Hardly a world-ending problem, but my point is simply that C runtimes are a pain everywhere.
> Ideally you'd like to build for all targets, including older systems, from a single, modern environment (this is trivial in Windows)
https://github.com/sjmulder/netwake does what you're talking about, but it does a lot of gymnastics to make it work, and it also needs to use MinGW rather than MSVC for that to be the case.
> You get a new Glibc, old binaries still work, it's fine.
Indeed, but when you need to build for an older glibc it's not so simple. This is a common use case, since e.g. AWS's environments are on glibc 2.26.
Ideally you'd like to build for all targets, including older systems, from a single, modern environment (this is trivial in Windows) -- and you can do some gymnastics to make that happen[1] -- but in practice it's easier to just manage different build environments for different targets. This is partly why building Linux wheels is so convoluted for Python[2].
Hardly a world-ending problem, but my point is simply that C runtimes are a pain everywhere.
1. https://stackoverflow.com/questions/2856438/how-can-i-link-t...
2. https://github.com/pypa/manylinux