I didn't realize bringing this up to date would take as long to tinker around with as it did (~ 8 hours), but...
Why was it such a pain?...
GCC 2.95.3 was Released in March 2001
Don't let the 2017 build date fool you. That's a 20-year old compiler, which we assume has the occasional Haiku patch here and there.
I knew the compiler that came with Haiku had been old. But when I was making decisions about letting go of C89 support (in the core) I figured that Haiku would be bumping their versions to support C99 at some point...
Nope.
The reason Haiku is still so far back appears to be because they depend on GCC 2.95 features that enable them to get binary compatibility with old BeOS packages.
You can install a more modern GCC if you like--but then you're off in the concerns of having multiple toolchains on your system. And presumably it's harder to link up against the HaikuOS C++ platform APIs. So I thought it would be a good proof of our light dependencies to build on what's there.
Note: Not Just Us, mbedTLS Dropped Their C89 Support
Even the most die -hard of low-dependency systems have let go of the 80s. In 2019, mbedTLS ceased supporting C89:
"We've internally decided to drop support for C89 in the development branch. We've removed
-Wdeclaration-after-statementto our build options inCMakeLists.txt. We run some builds withgcc -std=c99 -pedanticso we do test C99 compliance to a reasonable extent. Thus this issue is resolved."
Options Were Either Give Up, Or Revive the C++98 Build
At one point Ren-C was able to build as C++98. I stopped seeing the point of maintaining this option...as it was silly to be keeping track of which features I could use from C++11 in which permutations. So it was either you build as C or you build as C++11 (or higher).
But there really is no other choice with this GCC 2.95. The code is now styled:
printf("Here's a statement\n");
const char *str = "Here's a declaration after a statement";
The Haiku C compilation mode requires all your definitions to be before the statements:
const char *str;
printf("Here's a statement\n");
str = "Here's a declaration after a statement";
(Note: I hate that, because it makes maintenance much harder. But libuv is actually a holdout here...they're carrying the torch for C89 and committers still have to code in that style.)
In any case, C++98 was able to do that. So I revived the setting. It wasn't too hard...I just made it act like the C build almost all of the time. Hence no use of inheritance in REBVAL or anything like that. It deviates only when it has to for compiler semantics.
Building mbedTLS Was Saved By A --pedantic Quirk
While Ren-C was designed to compile as C or C++, mbedTLS is plain C. C++ compilers will choke on some of the permissive treatment of void*.
I thought there'd be no way around this; because C++ compilers have no way to disable these errors. ...or so I thought...!
As it turns out, if you raise the error reporting level with "pedantic" warnings, the warning machinery notices the problems before the error! And you can ignore warnings!
So oddly enough, I actually could compile the encryption code on Haiku (without having to go in and edit it).
Small Rewrites Needed To Dodge Compiler Bugs
Minor changes were required to code that was triggering GCC 2.95 bugs that prevented the build. I wouldn't be happy if I had to make a dozen changes for it, but it was a few.
I guess even if you write code that is correct, if you notice it triggering a compiler bug that may be a sign that it involves something hard for compilers to get right. One might be able to balance the annoyance of having to make the change with the potential that maybe fewer compilers would be getting that bit wrong.
Networking Doesn't Work, But After LibUV Switch, It Might!
I built the entirety of LibUV into the executable (even though I didn't technically have to). And the filesystem code--which is now on libuv--seems to be working.
The networking isn't on libuv yet, and isn't seeming to work. But maybe once it switches over, it will. I mentioned that Haiku was one of the explicitly supported platforms of libuv. So if all goes smoothly in that conversion, I imagine this will work!
No Action Item Here, Just Proving It Could Be Done
This was a good head-check of what exactly has changed as Ren-C has refactored and evolved. Letting certain dependencies creep in can make your source less adaptable and agile...and this helps be assured that things are still on track.
What's important here isn't "oh, now we can have millions of HaikuOS users". Rather it serves as another example of managed dependency control--to lend confidence to the idea that porting to other new ones should be easy enough.