Check if WebKit can be built

[Dmitry A. Kuminov]

We should try to find out what are the requirements of the WebKit? module and build it if we can.

The last time I checked it required GCC 3.4 and above. Now we have GCC 4.4.2 but there are some more dependencies for WebKit? in Qt4 it seems.

[Dmitry A. Kuminov]

First, I need to merge r592 to src/3rdparty/webkit/JavaScriptCore and see how it goes.

[Dmitry A. Kuminov]

The Webkit build is incredibly slow. More than 5 hours already.

[Dmitry A. Kuminov]

It builds now (the makefile is 18 megabytes in size BTW!) but I can't link it: emximp, given the page size of 32768 KBytes (e.g. 32 MBytes) fails at the 2GB boundary generating the import library file (debug version). We apparently need to split it up but I'm still not sure if it will work (I will try a release build overnight).

[Dmitry A. Kuminov]

I managed to generate an import library for the release build of webkit (quite acceptable 17 megabytes with page size 256 KB). However, I cannot link it into a dll: emxomfld aborts with the message:

g++: error trying to exec 'emxomfld.exe': execvp: Invalid argument

The reason I suppose is that the size of the command line arguments block passed to emxomfld.exe exceeds 64 KB (the command line size is 70 something KB).

[Dmitry A. Kuminov]

Okay, calling emxomfld.exe manually made it link. The release version of QtWebK4.dll here is almost 17 MB in size while it's only 10 on Windows. Probably, this is due to the fact that we export every public symbol while on Windows, only the ones marked with declspec(dllexport) are exported. I will try the same here too.

[Dmitry A. Kuminov]

It works, the DLL gets significantly smaller (about 13 MB here) but this actually requires to change the whole exporting scheme to declspec(dllexport) in Qt.

Anyway, we will need a couple more days if we want to include webkit in the release. It's very slow; after every change like that I need to wait 6-7 hours for it to build.

[Dmitry A. Kuminov]

Okay, I managed to build the debug version of QtWebKit?.dll using
ddeclspec(dllexport) that doesn't require splitting to several smaller DLLs!

This should work for QtGui?.dll as well since it has a comparable size: this ddeclspec(dllexport) significantly reduces the amount of exports which caused most of the troubles as I understand.

[Dmitry A. Kuminov]

It's definitely worth it. I switched the whole Qt build to use declspec(dllexport) for exporting and the results are impressive: the average reduction of the number of exports in the DLL is more than two times, e.g. we had ~10000 exports in QtCore? and now only ~4200 (debug version).

Also, I disabled the DLL split for the QtGui? DLL since it seems to work fine as a single module (and occupies 4 MB less space, 83 MB instead of total 88 MB taken by three separate DLLs).

And we also don't need to call emxexp as a separate (and quite a slow) step to generate the DEF file with EXPORST since the exports are taken right from object files now.

Note that this new method is the default now, the old one is still accessible using the "export_all" qmake CONFIG flag. Also note that using the DLL split functions will automatically turn the "export_all" mode on.

[Dmitry A. Kuminov]

I solved the initial problem (the emxomf thingy and r676), the browser application now works (it's actually a full featured modern web browser, you should check it).

There are two other problems I mentioned. It sometimes doesn't reload the CSS from its cache so you need to press F5 to fully reload the page and get all the nice formatting and stuff.

Another is an occasional crash in QtWebK4.dll. Here, it sometimes happens when I visit youtube.com and press on some movie: normally, it show a message saying that you need to install a flash plugin but sometimes it crashes instead.

Unfortunately, idbug stopped working here so I can't track the problem so far.

[Dmitry A. Kuminov]

Played with the release build for some time but couldn't make it crash. Probably, the crash is specific to the debug version so we should leave it as is for now.

[Dmitry A. Kuminov]

Ufff, I fixed another O_BINARY case in r679: QTemporaryFile was doing LF <-> CRLF translation too and this is what broke the cache. Now the cache works fine as well as downloading files and images from the browser to the local disk (which was also affected by the broken cache).

[Dmitry A. Kuminov]

Still cannot find exactly why it crashes. Taking the size of the library it's almost impossible to debug: idbug can't provide source level debugging (because there are too many too lengthy symbols), procdump is spartan and doesn't show all the symbols (perhaps, again, due to the size).

As we don't have anything like valgrind or efence, I have to use the printf approach but it takes ages to recompile webkit after a single change in the header.

I will most likely release 4.6.2 without the fix (unless I'm lucky).

[Dmitry A. Kuminov]

Okay, it's a heap memory corruption: after the next call to JSArray::put(), the contents of the JSArray object changes. Searching for what is doing that.

[Dmitry A. Kuminov]

JFTR. One step closer. The corruption happens when the garbage collector routine (collect()) gets executed, while doing the sweep() method within it. I'm trying to understand the heap structure now.

[Dmitry A. Kuminov]

The bug is fixed in r726. That was a tough one (to find). The browser demo application doesn't crash any more here. Closing this defect.

[Dmitry A. Kuminov]

Unfortunately, I changed the webkit headers, so I have to rebuild it twice which requires 4-6 hours. I will work on Java in the meantime.

[Dmitry A. Kuminov]

JFYI, it's r728 that caused the full webkit/jsc recompilation.

[Dmitry A. Kuminov]

And of course, the compilation took longer -- only the debug build lasted 5 hours. Waiting for the release build now.