I’m a little stuck. Last night I wrote a trivial startup program to make sure linking and calling into WebKit was working correctly:

#include "config.h"
#include "Logging.h"

extern "C" {

void webkit_init(void) {


int main(void) {
    return 0;

It compiled fine, but the link failed:

There are undefined symbols in 'ArosLauncher':

All the bits of information I need to resolve this are scattered around (if they exist at all), but what I’ve learnt is this. WebKit is compiled with -fPIC, which produces position-independant code. This is what you want when producing an ELF shared library. Essentially what it does is setup an offset table to hold the locations of all the global symbols in the library, and causes the generated code to access those symbols through the table instead of going direct. Later, when the library starts, the runtime linker fills in this table with the correct locations to all the symbols. This allows the OS to place the library anywhere in memory it wants, rather than at the location the library was compiled for initally. This is all great stuff than doesn’t make the slightest impact on AROS, as our shared libraries don’t work this way. Well, they do conceptually, but thats a topic for another time.

I’m compiling all this code into a static library, but because it was compiled with -fPIC it has lots of references to _GLOBAL_OFFSET_TABLE_. Here’s where I’m unsure of what’s happening. Either GCC is not setting up the offset table because our patches to make it work on AROS don’t enable it (reasonable, since we don’t have support ELF shared libraries), or its just implied that if you’re linking with a static library you won’t need the offset table and are expected to compile with -fPIC. I spent a lot of time last night believing the former, but after being completely unable to find anything in the GCC code that supports this, I’m really starting to lean towards the latter.

Which brings us to the next problem. Currently AROS WebKit is build using qmake, the build system for QT. I chose this because it was the easiest way to get a cross-build running at a time where I had no real idea what I was doing. It would seem that its currently setup to build a shared library, which I’m hacking around at the last stage to make it output a static library. I haven’t found an obvious way to disable -fPIC yet.

This highlights the next issue. qmake is not going to cut it going forward. Actually, none of the existing WebKit build systems are really suited to cross-building - its all hacks so far. Before long its going to need a real build system. I’d like to use plain GNU make so that there won’t be an issue with compiling the mess on AROS, but there’s still going to have to be some stuff copied from the AROS build system to support setting up the Zune stubs, for example. That suggests just using mmake directly, except that I have my reservations about its long-term suitability for anything. The build system is not something I want to debate here, I’ve said my piece about it elsewhere and I’m deliberately not discussing it until I have time to do my own experiments.

So here I am at a bunch of apparent deadends. I’m going to spend a little more time right now trying to bend qmake to my will, but this whole mess is rapidly getting out of hand. I believe a sigh is the appropriate action at this point.


Update 12:53: Figured out how to turn -fPIC off, and I now get why it wasn’t working. I now see logging output on the console, awesome! A better build system is still required.