Holiday brewskis for 10.4

Merry two-days-after-Christmas and Happy Holidays. If you were a good little boy-or-girl-or-thing, I hope Santa-Father Christmas-the folks-the person you are blackmailing brought you many nice things. If you were not a good little boy-or-girl-or-thing, bituminous is lovely in the fireplace.

The compiler upgrade is all but complete, and there will be build system changes to match starting with 19. I am strongly considering a formal beta for 19 to make sure we catch all of the widget changes and find any 10.4-specific bugs, as well as the standard 19 unstable release.

I have been made aware by its creator, Misty DeMeo, of "Tigerbrew," a Homebrew port to PowerPC Tiger (our favourite operating system). For those unfamiliar, Homebrew is one of the newest and increasingly popular package managers for Mac OS X (even Mozilla has started using it), but it has historically required 10.5 and I have heard of issues with it on Power Macs, both problems of which hopefully Tigerbrew will mitigate as it matures. While we are ordinarily a MacPorts shop and our workflow mostly revolves around it, Homebrew definitely has some nice features and a Tiger version only increases our choices for maintaining our software (besides, of course, good old standards like Fink, which David Fang still maintains TenFourFox as a package for). You can read more about it at its Github, or, to jump in the water, ruby -e "$(curl -fsSkL raw.github.com/mistydemeo/tigerbrew/go)"

Also, just for your amusement (please don't comment on the bug, this is just for chuckles), enjoy this bug report that we all sympathize with.

SDLMAME builders and other ldx3 users: switch to ld64

I note in this forum thread that the indefatigable bunch making SDLMAME builds for PowerPC are also using Tobias' ported Xcode 3 linker (a/k/a ldx3) with gcc 4.0.1, the one we originally offered starting with TenFourFox 5 and still use on the TenFourFox 17 stable branch (the last branch that will use it). It appears they were bitten by the same linker issue we were, based on the crash dump and the size of the binary.

Unfortunately, their forum has a very byzantine way of creating accounts due to spammers, so I'll post it here and hope they and any other users of ldx3 notice: since we're moving to gcc 4.6.3 for 19, we don't need nor will we update ldx3 anymore because a proper 64-bit ld with Tobias' island fix is part of the standard MacPorts gcc46 package "for free." But you can still get that ld separately for other purposes; just port install ld64 to install it by itself (and you can just symlink it to ldx3 if you want to keep your build system the same way), which will work just fine with Apple gcc 4.0.1. We will keep that port up to date so you can keep using it.

Fink and Homebrew users, just apply the patch to Apple's ld 97.17 sources.

PowerPC builders gotta stick together, you know?

タイガーで絵文字を楽しみましょう！Taigaa de emoji o tanoshimimashô! Let's enjoy emoji on Tiger!

Hora, hora! Mochiron, Taigaa de, emoji o shiyô suru koto ga dekimasu ... oh wait, sorry! Let's try that again in English.

Emoji are hot (possibly even, ATSUI? ha ha!) on iOS and Apple introduced an emoji font, complete with little colour smilies, for 10.7. Firefox even supports this font, sort of (there are some bugs in this support and in fact I had to back this out partially because of the secret flawed CoreText in 10.4 which interferes with Mozilla's Cairo-based emoji rendering).

Naturally the good versions of OS X, which is everything before Lion, don't have direct emoji support, let alone those fun little colour icons. However, if you're willing to accept a monochrome non-animated substitute, you can get emoji on your Power Mac, because emoji are really just Unicode characters at their most basic and if you could find a font that had the emoji in the right place in the character map, it would "just work."

Fortunately, there is such a font, and that font is Symbola. It works just fine with OS X, and with TTConverter will probably even work for OS 9 and Classilla. Warning before you install: when you try to do so, Font Book will freak out (correctly), saying the font is missing OpenType information. While it appears to work fine without it on 10.4, installing this font is of course at your own risk. Just unzip the file you get, double click to open it in Font Book for installation, and after installing it (and saying "yes, I don't care if my computer blows up") quit and restart TenFourFox to ensure it recognizes the new font.

Now you can see my cat, instead of a "no character here" box: 😺

Issues 194 and 195 are now fixed, though I'm thinking of even faster ways to enumerate fonts, but this still should cut down on lag with people who have a lot of fonts even in this state. And, since we've just added another font, that should help that much more. Yatta!

gcc update succeeded! (plus: four heads are better than one)

Our failure upgrading to gcc 4.6.3 in the prior post turned out to be a canary in the coal mine (though in retrospect issue 169 was the first manifestation of the underlying problem) because soon after, Tobias started finding problems in some of his test builds for AuroraFox, and SeaMonkeyPPC wouldn't run at all either. Tobias was able to show that Apple ld had generated a bad branch in the Mozilla megalibrary XUL (which has been an intrinsic part of Firefox and all of our PPC community derivatives including AuroraFox, Tenfourbird and SeaMonkeyPPC since Mozilla 5), and my analysis showed it to be completely out of range. Ben's and my thought was to slim down XUL, but Tobias was able to find the bug in Apple ld to properly handle such large branches, hikerxbiker was able to prove it worked against SeaMonkeyPPC, and this post is, voila, coming to you from a debug build of 19.0a2 on the G5. So TenFourFox lives once more. Tobias has upstreamed this linker fix to MacPorts; our Fink users should make sure they make a similar fix themselves.

This is why it's wonderful to have a community working on continuing the PowerPC OS X Mozilla ports. As an example of what happens when there isn't a community, it looks like the OS/2 port of Firefox, one of the longer running Tier-3 community builds, is running out of gas; they're still stuck on ESR 10 and the lone guy still cranking them out, Dave Yeo, doesn't have a lot of resources to turn to when things go wrong. They're already somewhat compromised in that WOFF downloadable fonts don't work right, so they're not fully Acid3-compliant as it is. I think this is going to happen to a lot of the smaller Tier-3 ports: ourselves and Landry Breuil on the OpenBSD side are about the only ones supporting big-endian hardware (WebKit even took big endian support out of YARR, the regexp library our JavaScript compiler uses, which we had to put back in), we don't see anything much going on with Solaris on SPARC these days, and I'm not sure what the state of Firefox is on the PPC Linuces since a lot of those users have migrated to WebKit-based browsers. It is entirely possible that the OS/2 port will end with Firefox ESR 10. And as an admirer of OS/2 back in the day, that's very sad to see happen.

Fortunately, that won't happen to us, at least not yet. Most of the 10.5 compatibility code has been restored successfully (and backported to 10.4, of course), and I have not found any major bugs in this version except for a strange problem with favicons I'm not able to fully track down yet. Now that we're running on a current compiler for a change, I was able to jettison all the ugly fixes I had to make for gcc 4.0.1 and make our changesets smaller and easier to maintain. When 19 goes into beta I'm going to pull it again and possibly generate some opt builds for people to play with, starting our new unstable branch off right. I'm also going to begin work on our PowerPC IonMonkey port and let's hope we get it done before Mozilla sends JaegerMonkey to that great tracing compiler in the sky. Remember: no plugin support exists at all in 18+.

For the stable branch, we will issue a fix for issue 194, which is a Mozilla bug actually but that doesn't appear is being backported to ESR17, and I'm looking into issue 195 where the check for dud fonts introduced with issue 171 can slow down the browser when it gets run unnecessarily, though this probably won't be fixed in time for 17.0.2, our "Best Commodore 64 Monitor Ever" release.

gcc update failed!

Not good news. TenFourFox 19 will build with gcc 4.6.3, but it will not start on 10.4, and it appears that the libxpcom it builds does not work with Tiger dyld. JavaScript works, but JavaScript does not need XPCOM. It even crashes on a binary that is simply linked to libxpcom.

This isn't a port-ender, but it certainly constrains us greatly because we won't be able to upgrade the toolchain in the future. It is possible we could hack the build system to build with 4.6 for the complex JavaScript portion which is requiring a lot of hacking to build with 4.0.1, then build the rest with 4.0.1 and glue it all together, but this is clearly a desperation idea.

If you like beer, or if you simply like fatuous adoration (your choice), see if you can succeed where I have failed in issue 52. You need to have the MacPorts gcc46 package installed. If we can't fix this by the time 19 makes it to beta channel, then we press on with gcc 4.0.1 for as long as it lasts, and it will be time for a long hard discussion on what will trigger dropping source parity. (David, does Fink's gcc port have the same problem?)