I fixed Windows native development

Ok that does sound a bit different.

I wish the post was clearer (though I'm not sure what that looks like). I've made the same mistake interpreting it, then had to go back and reread it a few times.

> Security comes before a lot of things but not before accidental breakage.

It didn't really sound accidental, though the bugzilla report sounds like they underestimated the impact. But I'm quite sure they were aware this would break at least some old software, it's not like it's hard to understand what exactly is happening here. Old software (or rather, builds) used executable stacks by default, and some edge cases used them for some time after that. I'll say they probably should've done a warning period.

> If you say "our compat guarantees are so strong you shouldn't keep track of versions at all",

What I said was you should never pin a glibc version, not to not keep track of versions at all :). I will admit this is hazy if you build binaries to distribute; in that case you probably want to intentionally use an old glibc. But that's not exactly a "pin", that's a "what's the oldest you want to support". The software being built basically makes no difference; glibc will do what it does, the only limit will be placed by features added in newer glibc versions. The binaries produced from that, running on a new system with any newer glibc, have AFAIK last broken during that S390 incident I linked. (e.g. you wouldn't have gotten executables requiring executable stacks out of a normal GNU tool chain for quite some time by now. It's still possible to intentionally mangle your code and build options to get that result, but you need to either be trying, or do relatively cursed things [like Mono probably some binary loading shenanigans]).

Either way — never pin glibc. And if your cmake or whatever complains about a glibc version conflict, remove the pins and use the newest version involved.

(And about the execstack thing — I'm happy to hear your complaints if and only if you show up with an actual report of breakage that you encountered. No 3rd party phoning. Because what's at question in this case is the actual impact size, which to me seems quite limited.)

> A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.

That's not how DSO versioning works. Unless it was a horrible disaster, the old functions would remain available, but you'd be required to jump through hoops to build new software against it.

Because glibc ships basically their entire version history in the library binary. That's the thing with DSO versioning.

I do wonder if they could've done some versioning trick with the execstack thing, the problem there is that it's more about global system behavior than actual exposed ABIs. (By the way, libc isn't even what you would be "pinning" there, it's libdl. Splitting hairs though, as that's part of glibc.)

I don't care if my package manager is provided by my OS or by some third party--I only want to deal with one package manager. Currently we have these Matryoshka dolls where there are package managers inside package managers, and each of them manage their own distinct trees of dependencies.

In RHEL8/9, there is a command "scl" which works by updating the PATH... so you can run "scl enable gcc-toolset-9 bash" to start a new bash shell using GCC 9.

In RHEL10, instead of "scl", each toolset has an independent command (actually just a shell script) like "gcc-toolset-9-env bash" which does the same thing

chroot or LD_LIBRARY_PATH isn't necessary, changing PATH is enough

Or in fact – this isn't RHEL scl system, but some other distros – some distros install alternative compilers using a prefix, so you just do `CC=PREFIX-gcc` (assuming you have a Makefile configured with the standard conventions)

e.g. for hobbyist/recreational reasons, I have done MS-DOS software development under Linux before. The DOS cross-compiler gets installed as "i586-pc-msdosdjgpp-gcc" so I just do "CC=i586-pc-msdosdjgpp-gcc make" to build my project for DOS instead of Linux.

Similarly, different clang versions are often installed with a version suffix. So in another project I had, I'd do "CC=clang-11 make" when I wanted to use clang 11 and "CC=clang-15 make" when I wanted to use clang 15. (You can tell from the version numbers I haven't touched that hobby project of mine for quite a while now.)