webkit2-gtk-devel: Patches to build WTF on Tiger/PPC

[evanmiller]

Description

Backporting webkit2-gtk by a single OS version is clearly an undertaking, so taking one bite of the elephant at a time. Included are patches to get the WTF (Web Template Framework) component building on Tiger/PPC. Should work with Leopard/PPC too, and hopefully doesn't break anything meantime. Fixes warnings in patch-ramsize.diff (+ remove unneeded import of dispatch.h) while we're at it.

I have sent one of the included patches upstream: https://bugs.webkit.org/show_bug.cgi?id=229647

The component now patches and builds on my machine but that's all I can vouch for.

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.4.11 8S165 Power Macintosh
Component versions: DevToolsCore-798.0; DevToolsSupport-794.0

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Notifying maintainers:
@kencu for port webkit2-gtk-devel.
@dbevans for port webkit2-gtk-devel.

[kencu]

Oh you are a sucker for punishment !

I spent quite some time on this a year or two ago, hacking in all the fixes to get it build back to SnowLeopard and on all the systems in between (every one of them had idiosyncrasies). I just plain ran out of enthusiasm at that point and left Tiger and Leopard off the list.

Looks like reasonable changes to me.

Apparently the newer versions of webkit2-gtk have some deal-breaker changes that will cause headaches (so say the folks over a 'nix, who took all my patches, complained about them some, but apparently just used them more or less verbatim anyway). They have a (maybe) newer version running on macOS. I tried to get to it, but I just can't really follow how 'nix is supposed to work, despite an evening of plugging away at it.

I'll give these a try.

Right now I am trying to get a coherent toolchain running smoothly on SnowLeopard for PPC, (which unfortunately is not going to run on your G3 as it requires a 7400-series or better.)

[kencu]

because I see this PR doesn't actually fix the build of webkit2-gtk-devel on Tiger or Leopard, and because it took me forever to get the various patches and portfile bits into an understandable state, I think we will keep this here as a PR and a "WIP" for some future date when it does perhaps actually build through.

If we get to that point, then we can figure out some neat-and-tidy way to bundle this all up into something discrete.

be aware, though, that I have already been getting pressure from consumers of webkit2-gtk to update it to some newer version (there is one browser in particular that uses it uniquely).

Again -- heavy work. I am not sure it's possible in the end, but it's a great challenge.

If you are looking for something very concrete to do, libuv has been held back for a while on Tiger and similar. That is a manageable meal to take on, and will need updating soon. There is a test suite in it that currently runs on Tiger, and I use that to see just how close we are to something useful.

[evanmiller]

Well the JavaScript engine is looking like a pain in the donkey, so don't hold your breath. Been discovering all of the platform oddities on Tiger/PPC, like sizeof(size_t) > sizeof(void *) and sizeof(bool) == 4. There are some templating horror shows in here that unfortunately I can't unsee, so if my neighbors start complaining about nocturnal screaming you'll know the cause.

Maybe I'm optimistic but eventually I'm hoping to get a usable web browser on my little steam engine... TenFourFox is barely usable and so for quick browsing I've been popping open links -g, which I guess is a good throwback to the early 90s but doesn't quite work as a daily driver. Figured WebKit would be faster than TenFour but that remains to be seen with the GTK and X11 layers in the mix.

Good luck on SL/PPC! I'm pretty content with Tiger, feels like anything's possible with GCC 7 on here. Happy to help sell patches upstream if WebKit hasn't raced too far ahead of us.

[evanmiller]

And yes WIP is appropriate since it's still not a complete build. But according to CMake we're up to 11.7%!

[evanmiller]

Well – I actually managed to compile JavaScriptCore on the little chugger. There was some vestigial PPC code hanging around that I plugged back into, so I'm somewhat more optimistic about this than my recent mozjs60 attempts.

Anyway, the jsc binary crashed on startup... but I have a stacktrace!

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000028
0x01134c70 in JSC::Heap::addFinalizer ()
(gdb) bt
#0  0x01134c70 in JSC::Heap::addFinalizer ()
#1  0x013962e8 in JSC::JSSegmentedVariableObject::finishCreation ()
#2  0x013597f4 in JSC::JSGlobalObject::finishCreation ()
#3  0x0001dd4c in GlobalObject::finishCreation ()
#4  0x0001ebd8 in GlobalObject::create ()
#5  0x00015104 in jscmain ()
#6  0x00023fac in main ()

Crashing code:

void Heap::addFinalizer(JSCell* cell, Finalizer finalizer)
{
    WeakSet::allocate(cell, &m_finalizerOwner, reinterpret_cast<void*>(finalizer)); // Balanced by FinalizerOwner::finalize().
}

Calling code:

void JSSegmentedVariableObject::finishCreation(VM& vm)
{
    Base::finishCreation(vm);
    setSymbolTable(vm, SymbolTable::create(vm));
    vm.heap.addFinalizer(this, [] (JSCell* cell) {
        static_cast<JSSegmentedVariableObject*>(cell)->classInfo()->methodTable.destroy(cell);
    });
}

Running jsc outside of gdb, I get a SIGBUS (Misaligned address error). I'm not sure if there's something funky going on with the closure, or if a NULL is being dereferenced, or what exactly. Does anything about it look familiar to anyone?

The rest of the compilation is continuing to keep my kitchen warm. 34.8% and counting...

[kencu]

on 10.6 I had great hopes that webkit2-gtk with epiphany or similar as a front-end would be the browser solution going forward. That was in fact why I spent so much time a few years ago making webkit2-gtk work all the way back to 10.6 i386 and on all systems in between.

Unfortunately, it is basically unusable. webkit2-gtk has a couple (two exactly?) processes that pass objects back and forth between them to allow it work. I think it uses dbus, I forget exactly just now the messaging protocol. Anyway, at least on 10.6, the kernel support for that messaging protocol just can't support the demands of webkit2-gtk. Probably the issue is the maximum size of the message, I thought -- webkit2-gtk passes back and forth large messages. Perhaps something else -- timing issues, etc.

I asked one time on the webkit-gtk mailing list for some ideas, but everyone on darwin uses Apple's webkit fork of Webkit, and at that time, only MacPorts could even build webkit2-gtk so there were no users up there who had any good idea how to debug it.

There are certain env vars that can be set to increase the debugging messages sent by the messaging system. It's not easy to debug, at least for me.

So in the end I gave up on webkit2-gtk for the time being as the browser for older systems, and put my focus on TenFourFox instead. I got that working on Intel systems with the help of Riccardo, a keen user in Italy, over Christmas in 2018. It works OK for me, but now Mozilla has dropped the fork, so no more updates for Cameron (the TenFourFox maintainer) to crib from. So he dropped TenFourFox as well.

What I do now is use XQuartz on < 10.7 to run epiphany, which is actually installed on a $25 box running Ubuntu 21.04 but works quite reasonably as a client for XQuartz, and that actually works quite well for me. Or use TenFourFox.

[kencu]

Check out surf by the way. It also uses webkit2-gtk, and is much much simpler than epiphany, and I found that to be marginally more stable than epiphany, although it still crashed so often running webkit2-gtk I gave up on it as well in the end.

[evanmiller]

Thanks for the additional context and perspective. Even a slow webkit2-gtk with JavaScript disabled would enable some things (e.g. yelp) that aren't currently possible on PPC. If large-message IPC was the bottleneck in your testing, that's actually somewhat promising in that maybe there's a "simple" fix. Maybe not, but I'd rather have that situation than one where things are slow for 100 different reasons...

In any event, with a couple more local patches the compile is up to about 78% here. Once it's done I should be able to start tinkering with the crash posted above. I've hit a couple of issues that made me wonder whether a newer compiler would help. So let me know if/how I can help with the gcc11 effort.

[kencu]

Here is what I did for "yelp" on PowerPC a few years ago. It works great, but I could not sell it to MacPorts.

https://github.com/kencu/LeopardPorts/blob/master/gnome/yelp/Portfile

[kencu]

The large message IPC issue is hardwired in the kernel, I'm afraid :<

[kencu]

I also had another version of the yelp Port for PPC that installed a small shell script that opened the gnome Help URL using the default browser. Maybe I can find that one somewhere. It's a lot more likely to be useful than yelp will ever be on PowerPC -- it's crazy anyway to try to rebuild a whole webkit2-gtk installation just to browse the html help -- TenFourFox already browses the html help perfectly well.

[evanmiller]

I also had another version of the yelp Port for PPC that installed a small shell script that opened the gnome Help URL using the default browser.

Maybe yelp-lite? Seems useful!

[evanmiller]

This is going to be a large-to-impossible project – I'd rather not take up the CI resources until I have something working locally, so closing.