TenFourFox on Intel OS X 10.4

[CC_333]

Hi,

I have an "unsupported" installation of Mac OS X 10.4 on my early 2008 Mac Pro, and I'd like to run TenFourFox on it.

It works when I run it on a Mac which came with 10.4 from the factory, so it's perfectly capable of running on an Intel CPU, but it won't work on this here Mac Pro. I launch it, and it just freezes with a beach ball before it get's anywhere.

There isn't anything special with the Mac Pro's installation, except I fiddled with the graphics driver to get the video card working fully (that was the main hurdle in getting 10.4 to run smoothly).

Any ideas?

It's no big deal, I just wanted to know why, and if there's a way to fix it.

c

p.s. This is for another topic, but what about compiling a version of TenFourFox (or some other variant of FireFox) for 10.4 Intel?

 

[theos911]

Are you using the G3 version?

 

[ClassicHasClass]

It's probably the JavaScript compiler -- it plays fast and loose with stack frames to get everything to fit in the limited OS X PPC stack range. If the browser starts okay in safe mode, that's the problem (hold down Option as you start it). And, like theos911 said, use the G3 version.

I get periodic questions about an Intel TenFourFox, but I don't use Intel 10.4, and I have a standing rule I don't support software I don't use (which is sort of a question about TTYtter since I don't use Twitter much if ever anymore -- moved to App.net). However, I would be happy to point people towards such a build and maybe even host it.

It would not be difficult to do: you'd have to undo the current JS compiler and point it to the built-in x86 one instead, change the AltiVec code to point to the built-in SSE2 equivalents, and make sure we haven't made any big-endian assumptions (usually we're dealing with code that makes little-endian assumptions). This is non-trivial, but the x86 code obviously is already in the code base; you just have to get everything pointing back to it, since I didn't really design the source for cross-compilation. Then you can use the 10.4-widget, graphics and font support, which should work with no changes.

Interested? Grab it, give it a spin, let me know how it goes. But I have too much on my plate to support it myself, especially since I have no way of really testing it.

 

[ChristTrekker]

It would not be difficult to do: you'd have to undo the current JS compiler and point it to the built-in x86 one instead, change the AltiVec code to point to the built-in SSE2 equivalents, and make sure we haven't made any big-endian assumptions (usually we're dealing with code that makes little-endian assumptions). This is non-trivial, but the x86 code obviously is already in the code base; you just have to get everything pointing back to it, since I didn't really design the source for cross-compilation. Then you can use the 10.4-widget, graphics and font support, which should work with no changes.

I've often wondered what kind of issues these are. I would think that unless you're dealing with assembly code, most of these concerns are abstracted out. Just recompile for the right target arch and you should be good, right?

 

[CC_333]

Are you using the G3 version?

Yes. And the G4 version -- both with the same results.

It's probably the JavaScript compiler.... If the browser starts okay in safe mode, that's the problem (hold down Option as you start it).

I'll give that a try.

I get periodic questions about an Intel TenFourFox, but I don't use Intel 10.4, and I have a standing rule I don't support software I don't use (which is sort of a question about TTYtter since I don't use Twitter much if ever anymore -- moved to App.net). However, I would be happy to point people towards such a build and maybe even host it.

It seems like something someone should do if they have almost unlimited free time, although with even the oldest Intel Macs being supported by Snow Leopard, it's probably pointless. I was just wondering because I find 10.4 to be quicker and lighter, especially on the Mac Pro.

It would not be difficult to do: you'd have to undo the current JS compiler and point it to the built-in x86 one instead, change the AltiVec code to point to the built-in SSE2 equivalents, and make sure we haven't made any big-endian assumptions (usually we're dealing with code that makes little-endian assumptions). This is non-trivial, but the x86 code obviously is already in the code base; you just have to get everything pointing back to it, since I didn't really design the source for cross-compilation. Then you can use the 10.4-widget, graphics and font support, which should work with no changes.

By not difficult, do you mean not difficult for a programmer, or not difficult for someone who knows almost no programming?

Interested? Grab it, give it a spin, let me know how it goes. But I have too much on my plate to support it myself, especially since I have no way of really testing it.

I'm interested, but I don't think I have the skills necessary to pull it off right now. Maybe someday...

I've often wondered what kind of issues these are. I would think that unless you're dealing with assembly code, most of these concerns are abstracted out. Just recompile for the right target arch and you should be good, right?

That seems logical. That's how Linux does things, isn't it?
Anyway, thank you for the information.

c

 

[ClassicHasClass]

I would think that unless you're dealing with assembly code, most of these concerns are abstracted out. Just recompile for the right target arch and you should be good, right?

No, because while it will generate Intel code for the JavaScript compiler source, that Intel code when it runs will be generating PowerPC code. Like I say, I haven't really made the changes for crosscompilation because it's only building for PPC, and I don't have any way of testing them. Some stuff I added is hardcoded to build PPC and the stuff that isn't, I haven't tested.

By not difficult, do you mean not difficult for a programmer, or not difficult for someone who knows almost no programming?

The former. It's not a trivial change.

I have to say this candidly: if you're on a legacy machine and you want continued support, you're going to be doing it yourself. I write TenFourFox because I have a need. It just happens to be a need a lot of other people have, so I make it available to them, but I write it first and foremost for me. So if you have a need for it, go for it -- working on Classilla taught me a lot about Mozilla code, which I leveraged working on TenFourFox. Dive in and learn. I wouldn't be as familiar with the source and the way the browser is constructed without getting my hands dirty. I'm certainly willing to give suggestions and tips.

 

[CC_333]

Hi,

Well, I got it working! I don't know how or why, but reinstalling the OS seemed to fix it.

In using it, I have found two issues which could pose some difficulties:

1. Due to it being PowerPC, it runs through Rosetta, which makes it rather slow (this is to be expected, so I'm not surprised)
   
2. Javascript doesn't seem to be working. It causes all kinds of instabilities, which turning it off eliminates. This is presumably because it's optimized for PowerPC using features of the CPU which Rosetta doesn't emulate (again, not surprised)

So far, it seems to be working OK despite these issues, so I'll use it to supplement Safari for now, rather than replace it (which was my original intent).

c

p.s. Has anybody out there compiled and ran the official Firefox source code for Intel Mac OS X 10.4?

 

[ClassicHasClass]

Rosetta, at least from the little amount of documentation Apple published, appeared to have issues with things that generate PowerPC code and then execute it. However, TraceMonkey worked fine with Rosetta. JaegerMonkey just appears to be too much for it, though. I'll probably document this in the FAQ.

In answer to your other question, it will not compile on 10.4, and it probably won't compile on 10.5 either, because as of Fx18 gcc 4.4 is the minimum requirement (or Clang). The TenFourFox changes add a lot of hacks to get it to run on gcc 4.0.1. However, the amount of hacking I had to do for 17 and some of the miscompilations gcc made scared me greatly, and we're moving to a 10.4-built gcc 4.6.3 for Fx19. The stable branch of TenFourFox 17 will be the last version that will build with Apple-shipped gcc.

 

[leitec]

Out of curiosity I decided to try compiling TFF 17.0.2 on Intel Tiger. It seems Cameron did quite a good job of keeping PPC-specific things #ifdef'd out, so the changes required were very small for the most part. It runs very well, with the Intel-specific optimizations from the main tree intact. It's slightly slower than mainline FF on newer OS X. For example, Sunspider ran in 343ms on 10.8 and 383ms on TFF/10.4 on my late '07 MBP.

In case anyone's interested, here are the notes I kept. Sorry, no patch--it was my first time using Mercurial. There's probably other stuff I missed (OpenGL stuff, maybe?) but it worked and was quite stable. With the hard work already done it took less than half an hour if you exclude the time spent compiling it.

-- patch 110055

nsprpub/pr/src/md/unix/os_Darwin.s -- remove ppc asm stuff

nsprpub/pr/src/md/unix/pratom.h -- remove references to stuff we took out of os_Darwin.s

-- patch 110013, 110018

write_vmx vs. write_sse2

xpcom/string/public/nsUTF8Utils.h -- remove two add'l MOZILLA_MAY_SUPPORT_SSE2 ifdefs vs. mainline FF's version

-- patch 109972

toolkit/crashreporter/client/crashreporter_osx.mm -- add CPU_TYPE_X86

toolkit/mozapps/update/updater -- "" ""

xpcom/threads/nsProcessCommon.cpp -- "" ""

-- patch 110058

gfx/thebes/gfxMacPlatformFontList.mm -- change if(0) to if(1) to revert big-endian changes

-- not associated with any patch

gfx/ycbcr/yuv_row_posix.cpp -- change .global to .globl, remove .type, add _ prefix to SSE ASM functions

dom/plugins/base/nsNPAPIPlugin.cpp -- change GLint to long in GMA9XXGraphics()

toolkit/xre/nsSigHandlers.cpp -- fpehandler() doesn't compile

to fix:

#include

#include

#include

remove __ from all names

use fp_control_t and fp_status_t

 

[ClassicHasClass]

leitec, would you be willing to generate such a build? I'll take the fixes; file an issue against me on Google Code. You should be able to recover the changes you made with a simple 'hg diff' in the root of the tree.

 

[leitec]

Hmm... yeah, I think I can do that. At the very least I can build the 17 series, since that doesn't require much in the way of new dependencies. I haven't yet tried to build the newer compiler for 19+.

I tried 'hg diff' but I get a diff including all of your patches, too. Perhaps that's because I started with a tarball and built the hg repo on top of that. I'll get you a diff somehow.

 

[ClassicHasClass]

We'll just start with 17. A lot of people have asked for this, but since I don't do Intel Macs, it's not a segment I can serve in. Open an issue on Google Code so we can track it.