← Back to context

Comment by manwe150

9 days ago

A few recent examples: many distros changed the flag for emuTLS on Windows, which gcc implemented as a hard ABI break for no essential reason. If you compile for enough platforms, it will print various notes that various alignments have changed in the struct, which has caused grief numerous times in the past few years for people I work with (many of the changes don’t come with notes, they just change alignment since new hardware comes out that has new features which need more and/or there were bugs previously, so they silently change it). There’s also win32 or posix threading, and sjlj vs structured exceptions, all of which are mutually incompatible. Oh, and then don’t get me started on ARM v6 atomics, which is some weird decided-based-on-compiler-flags-to-record-heuristics-detected-during-configure-of-some-auxiliary-header time, instead of using the current target’s ABI

Sure, the ABI does not change at all, if you know in advance where the landmines are. Though it does have quite few, especially for a large project with a huge surface area

I was talking about glibc; none of the things you mention relate to that. (Note glibc is not used on Windows.) I'm painfully aware of some of the breakage GCC occasionally causes (the atomics fall into that — but to be fair ARMv6 is also >10 years ago at this point, unless you're doing embedded, in which case you generally build the whole system anyway and don't care about these breaks.)

Also, just in case it's not clear, glibc has nothing to do with GCC.