WebCore Now Compiles for Haiku

Blog post by leavengood on Mon, 2007-11-12 05:40

I know I have been very quiet for a while in regards to my Haiku WebKit port, but that is because I've been in a long session of coding. I am happy to report that this weekend I finally got WebCore compiling for Haiku:

Link ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
Chmod1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
SetType1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
MimeSet1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 
SetVersion1 ../../../generated/objects/haiku/x86/release/WebKit/WebCore/libwebcore.so 

So what does this mean? Does it mean the port is now complete? Unfortunately, no it doesn't.

There are still some "stubbed out" classes in the Haiku platform code in WebCore, which means they don't do anything and just exist to make the code compile. Fortunately I have coded a lot of the needed platform files, but the ones which are stubbed out are some of the more complicated ones.

But I am very eager to finally get a simple web launcher running on Haiku to test the port, so I plan to work on this project after work this next week. For those not aware my (self-assigned) deadline for the WebKit Port Bounty on Haikuware is November 15th, which is this next Thursday. I think this deadline was a good motivator so I am glad I have it, but I don't think the port will be rock solid and "complete" by then. Keep in mind that the Qt port of WebKit is also missing a lot and has been worked on by many developers for more than a year. In addition WebKit originally came from KHTML which was a Qt-based HTML engine, so they have another advantage in that the design is Qt-friendly. Even the Windows port which is done by Apple employees who are experts on WebKit is still missing things that the main Mac OS X port has.

I don't say all this as some big excuse. I just want people to realize this is quite a big project and involves my learning the design of WebKit as well as aspects of the Haiku API I am not aware of. Plus as I have discussed before I have had to set up a new cross-compiler environment, port and then build four external libraries WebKit needs (CURL, ICU, SQLite, and libxml2), and write new Jamfiles for JavaScriptCore and WebCore so they can be built with the Haiku build system. I have also added missing features to Haiku that WebKit needed. In the end I think I will be a much better developer after doing all this, but it does involve a lot of work. I expect that once I get over this first hump of the main work for the port, other people will be able (and hopefully willing) to help. I do know at least one Haiku developer who has interest in helping a bit.

So what do I plan to deliver to satisfy the bounty? Well I have started working on "HaikuLauncher", inspired by the QtLauncher, which will be a very basic browser shell to drive the WebKit engine. I would like this to be able to load a web page and render it properly. Beyond that I'm not guaranteeing anything, at least for another few months until I can write a full browser (which is outside the scope of the bounty.)

Given this I hope the folks who contributed to the bounty can feel satisfied that their money was well spent.


Re: WebCore Now Compiles for Haiku

This is a huge advancement for Haiku on the web in my opinion. I love the predictability of khtml/WebCore.

Re: WebCore Now Compiles for Haiku


Re: WebCore Now Compiles for Haiku

I can't say it enough: Thanks for the hard work Ryan. I am really looking forward to what will become of your efforts. I can probably give you a hand testing the browser once you get to that point.

Re: WebCore Now Compiles for Haiku

Money well spent, no doubt. Can't wait to test any outcome.

Re: WebCore Now Compiles for Haiku

Ryan, thank you for your (hard) work!

I'm not keeping track any more of Haiku since it seems so scattered nowadays still I always found that KDE was a huge improvement for Linux usage and thus I think the webkit shall be another interesting piece to the Haiku puzzle.

Have fun (all)!

Re: WebCore Now Compiles for Haiku

Great work, Ryan! I see in the post, you'll be porting SQLite. In order to build Firefox, we've made some hacks at SQLite in the past (to work with native BeOS threading instead of pthreads.) Ideally, we'd find someone with enough skill to get the SQLite folks to add Haiku/BeOS as a supported platform. Feel free to contact me directly if you think our previous efforts might help your port.

Re: WebCore Now Compiles for Haiku

Hi Doug,

I was able to get SQLite 3.4.2 to compile in my cross compiler environment (with GCC 4), but the resulting binary could not create databases (it was some kind of locking issue.)

So I would certainly appreciate any tips or maybe some patches from you guys. But since Haiku has much better pthread support than BeOS, I'm not sure we need to change that part of SQLite for a Haiku port.

Also at first I thought I could dump support for SQLite because WebCore was only using it for storing favicons, and I figured I could make a Haiku specific version of the icon database using BFS file attributes. BUT, the WebKit guys recently added initial support for the HTML5 Client-side Database Storage, which is pretty darn cool. I would like to have that working in the Haiku port (eventually), and really all we need for that is a working SQLite.

Plus SQLite seems to be used in quite a few other apps, and I think it would be useful to have a fully supported Haiku version. Probably if I take a little time to debug it I can solve the locking issue.

Re: WebCore Now Compiles for Haiku

SQLite 3.4.2 is working correctly in Haiku. Locking issue is fixed http://dev.haiku-os.org/ticket/1791

Re: WebCore Now Compiles for Haiku

Hi Ryan!

Good news about sqlite. Not sure what to say about the inability to create databases. sqlite does seem to be the opensource db of choice for browsers, though. Under BeOS/Zeta, to make Firefox work we had to hack in a BeOS-specific module so we could use bthreads instead of pthreads. Rene Gollent did this work, if I recall (sorry if I got this wrong!) At the time we were working, Mozilla kept copies of the sqlite code in their tree, so we simply hacked the BeOS code into Mozilla without ever getting it into the sqlite CVS.

Today, Mozilla trunk builds simply import sqlite at build time instead of keeping a copy in Mozilla CVS, so our old hacks won't work but that's not so important since we can't build Firefox 3 under BeOS/Zeta anyway.

I guess what I'm really saying is that you and tqh might want to work together to get sqlite working in the cross-compiler since it's needed for both webkit and mozilla in the long run.