WebKit Port Complications

I have been documenting my progress on porting the WebKit project to Haiku on the Haikuware site, but decided to also post information here. You may want to read my previous blog article about this port and also the information at the WebKit bounty on Haikuware. Please consider donating to a bounty.

Before I started work on this port I asked in the #webkit IRC channel what the mimimum version of GCC that was required to compile WebKit. The general consensus was 4.0. So what does that mean?

Well let's talk a little bit about BeOS compilers. I won't go into too much history because I don't know it all. What is relevant to the current discussion is the newest GCC which can be used to compile BeOS-compatible programs is GCC 2.95.3 . This version was released on March 16, 2001. Yes it is that old, older even than the Haiku project. The original GCC 2.95 was released on July 31, 1999. Of course this ancient GCC has been nicely maintained and updated as much as possible by Oliver Tappe and others.

The problem with using newer GCCs for BeOS programs is the GCC project changed various important aspects of the compiler which affects how C++ is compiled after 2.95.3. These changes were to fix bugs and design flaws, so they were necessary, but the end result is older C++ programs and libraries will not work with newer compiled code. This isn't a big deal on fully open source systems with well-maintained software. Projects like FreeBSD and Debian Linux went through the "growing pains" of changing to newer GCCs years ago. They had to make sure everything was recompiled and packages all updated, so it wasn't trivial, even for them.

Haiku, on the other hand, has a bigger problem: it needs to support very old, unsupported "abandonware" like Gobe Productive. Though we can dream, it is doubtful the Gobe Productive code will ever be released, or even that someone who has the code will recompile it for Haiku. There may be several other such applications that at least a few people find useful and would like to use on Haiku. So for Haiku to truly be the successor to BeOS which can support these programs, it must use the older GCC 2.95.3.

So how does all this relate to my WebKit port project? Well like I said above WebKit is a modern code-base and it requires a modern compiler, probably at least GCC 4.0 (released April, 20 2005, not exactly brand new.) In fact this weekend I attempted to compile JavaScriptCore with GCC 2.95.3 and it failed almost immediately. The preprocessor couldn't handle even a fairly simple macro in the Platform.h header file, where various parameters for the WebKit-supported platforms are kept. Now I know this problem can be worked around. I'm sure the many other errors I would encounter could be hacked around too. So why don't I just do this? Several reasons:

• It will be tedious, frustrating and could take a very long time.
• The resulting mess would not ever be accepted by the meticulous developers on the WebKit project. This would turn my port into a fork, meaning I would have to manually integrate any changes from the "real" Webkit or maintain loads of patches. I do not want to do this. A clean port will most likely make it into the WebKit SVN repository.
• It is unnecessary because Haiku can already be built with GCC 4.1.2!

That's right, the Haiku code-base was "ported" to compile on GCC 4.1.2 quite some time ago. Using GCC 4.1.2 requires Linux though, and in fact I had never bothered to use this GCC until I got my new Linux computer which became my default Haiku development machine. This is also why I decided to port WebKit to Haiku on Linux, not BeOS.

So that solves this WebKit problem then, right? Well no, because as I said above a GCC 4.1.2 compiled Haiku would not be able to load older BeOS applications and the whole "backwards compatible dream" would be lost.

But wait, I forsee another solution, of course (hey I'm a problem solver.) I believe it is possible to create a "legacy" sub-system in Haiku to run older BeOS applications. All the core libraries that programs need when running, like libroot.so, libbe.so, etc. would be compiled with both GCC 2.95.3 and GCC 4.1.2. Newer applications would have a special code embedded in their ELF header to indicate they are newer. The runtime_loader, which is responsible for loading applications, would detect this code and link the application with the newer GCC 4.1.2 libraries. If the application does not have this code, the loader assumes it is a legacy application, and it is linked with the older GCC 2.95.3 libraries. Now there may be a flaw in this whole idea, but I believe it is worth trying.

But for the moment this issue can wait, because my priority right now is to get WebKit ported. I can continue on this work by compiling my own Haiku with GCC 4.1.2 to test the port, which is exactly what I've been doing.

My current issue is trying to figure out how to compile external libraries with the Haiku GCC 4.1.2 compilers. The Haiku build system is pretty well designed, but is specialized to do what it does: compile Haiku using the Jam build tool. I integrated WebKit into this system by writing Jamfiles for it, but that really isn't an option for all the various libraries WebKit depends on. So I need to find a way to either use the current compilers or compile my own for this specific purpose. Dealing with compilers isn't trivial so this may take me a while.

But I will report that I got JavaScriptCore to compile successfully last week. But I need to test it and that is what requires I compile external libraries (specifically I'm trying to compile ICU, the International Components for Unicode library.) If anyone has any tips or tricks, please let me know! :)