[kimixa]

> Modern clang and gcc won't compile the LLVM used back then (C++ has changed too much)

Is this due to changing default values for the standard used, and would be "fixed" by adding "std=xxx" to the CXXFLAGS?

I've successfully built ~2011 era LLVM with no issues with the compiler itself (after that option change) using gcc last year - there were a couple of bugs in the llvm code though that I had to workaround (mainly relying on transitive includes from the standard library, or incorrect LLVM code that is detected by the newer compilers)

One of the big pain points I have with c++ is the dogmatic support of "old" code, I'd argue to the current version's detriment. But because of that I've never had an issue with code version backwards compatibility.

[LegionMammal978]

Even -fpermissive is no longer sufficient for some of the things that appear in the old LLVM codebase. It's mostly related to syntax issues that older compilers accepted even though the standard never permitted them.

[o11c]

Well, one thing I've noticed about LLVM is that it blatantly and intentionally relies on UB. The particular example I encountered probably isn't what causes the version breakage, but it's certainly a bad indicator.

That said, failures in building old software are very often due to one of:

* transitive headers (as you mentioned)

* typedef changes (`siginfo_t` vs `struct siginfo` comes to mind)

* macros with bad names (I was involved in the zlib `ON` drama)

* changes in library arrangement (the ncurses/tinfo split comes to mind, libcurl3/4 conditional ABI change, abuse of `dlopen`)

Most of these are one-line fixes if you're willing to patch the old code, which significantly increases the range of versions supported and thus reduces the number of artifacts you need to build for bootstrapping all the way to a modern version.

[ummonk]

Rather ironic it relies on UB given the extent to which Clang + LLVM insists on interpreting UB in the most creative way possible to optimize code…

[SAI_Peregrinus]

Compilers are the ones who define what happens when UB is encountered. It'd be odd if they couldn't rely on their own behavior!

Some of it is deliberately undefined in the standard so that compilers can use it, e.g. it's UB to use a reserved identifier so that compilers & future standard versions can add new keywords. This is why C's boolean type first got named `_Bool` and C++ defines `__cplusplus`: identifiers starting with an underscore and a capital letter or with two underscores are reserved, and using reserved identifiers is Undefined Behavior.

Some of it is that the compiler authors know how their compiler will generate code, and can rely on changing internal uses of UB when they change the code generation.

[viraptor]

> zlib `ON` drama

Could you link to something about it? It's the first time I hear about it.

[o11c]

https://bugs.gentoo.org/383179