during the last months I've been trying on my spare time to port firefox3 to Irix. I started with a vanilla firefox3 source package, without using any other patches, and tried to compile using latest nekoware gcc. Unfortunately I have failed, but have reached to a point which I should share. The package compiles cleanly, but segfaults when running.

Here are the steps to compile firefox 3.0.1 on Irix using gcc:

Change configure to get the gcc version correctly, otherwise unrelated things break while running configure. Related bug: 449671. Also change configure so that -rpath-link is converted to -rpath, the proper ld option for Irix. Change configure to comment out -Wall in CFLAGS and CXXFLAGS in the -irix6 part because warnings stop the compilation.Related patch.

Fix the various Makefiles by applying Makefiles-for-Irix.patch. It fixes issues like gp_overflow(5) for the linker, removes some hardsetted -mips3 flags, fixes order of libraries on the ld command etc...

The package compiles but doesn't run. Many tests pass but others fail miserably (some xpcshell tests), and no debugger can help me. dbx 7.3.7 segfaults badly, gdb 6.3 reports a corrupted stack and gdb 6.8 hangs. Similar misbehavior when debugging the core files. I ended up debugging the debugger but had no luck... That's the primary reason for my failure.

To compile --with-system-png, the neko_libpng should be patched to support APNG.

I was using latest versions for cairo,glib,gtk,libpixman,pango. They all compiled easily under gcc, with the following small quirks in case you want to build them:

glib also needed a small patch, but this fix I think has landed to trunk, not to the stable branch.

I compiled cairo succesfully with --enable-glitz! This option exists also for firefox3. Imagine how nice it would be to have that beast accelerated with OpenGL...

TODO: compile with other compilers. Latest gcc or SGI cc. Find a fast system for the job, my miserable O2 was too slow, needed a full day for an unoptimized build.

That is all for now! I wish you better luck. Thanks to all the people who helped me one way or the other (joerg, alver on the IRC, nekonoko for the package updates). I will be out of town for a long time, so don't be insulted if it takes some time to answer.

I strongly recommend compilation with maximum warnings on anything except the most trivial projects, for instance how can configure correctly determine the APIs if you don't use the strongest warnings?

After two months of developing a patch, i have finally made some decent progress in compiling firefox 3.0.10 with mipspro 7.4.4 on my 6.5.28m O200 rig.In short, i can either make a shared firefox-bin binary with libxul.so or a static-linked one. Pity only that both will bomb out with the infamous Bus Error. This means that we're close, but that there are some serious byte alignment errors concerning some classes/structs.

This means we have to wade through all the tests and find and fix broken bits of code, in which i can definitely use some assistance. Thanks to Jimis we have the most problematic code fixed: the xptcall assembly part.

The main difference with GCC is that MIPSPro is extremely strict in preallocating space for classes in combination with templates. If you try to forward-declare a class by using its empty definition: class nsIFile; and then use any kind of constructor/destructor on this class, say f.i. nsIcontainer(nsRefPtr<nsIFile>){} MIPSPro will bomb out complaining about incomplete types or "no instance of nsRefPtr<blabla> matches * blabla" because it wants to know the complete compile size of the class in advance.Initially trying other C++ frontends doesn't seem to ressolve the issue: i tried with the default 7.4.4 frontend, the -Zf,_245 frontend from 7.4.3 and the -Zf,_330 experimental frontend.The fix is however surprisingly simple: in most cases commenting out the empty declaration and inserting the relevant header file with the nsIFile definition will fix the problem.

The only real problem is when classes are forward declared in the same header as their definition. In that case you have to completely turn the file upside down and juggle with some constructors/destructors.On other times these headers are created using idl files, so this means that you have to patch them after a compile error. Still coding om some idl files to fix this problem, but fortunately this only occurs once.

Anyway, watch this space, as i will publish the patch file and my .mozconfig tomorrow when i'm at my work, so everybody can start chipping in for help.

dexter1 wrote:In short, i can either make a shared firefox-bin binary with libxul.so or a static-linked one. Pity only that both will bomb out with the infamous Bus Error. This means that we're close, but that there are some serious byte alignment errors concerning some classes/structs.

You may know about this already, but perhaps 'sysmips(MIPS_FIXADE, 1, 0, 0)' could be used as a temporary hack initially so you can progress with the port. It enables an exception handler for alignment exceptions that will fix them on the fly (with the downside that each unaligned access now costs many extra instructions).

dexter1 wrote:In short, i can either make a shared firefox-bin binary with libxul.so or a static-linked one.

I think having a separate libxul.so, in a different / installed by default subsystem is the best way, as it would allow libxul dependant applications (I'm working on songbird lately) to have a dependency on this subsystem. On my dev system libxul.so is huge (51MB), and I guess it makes sense to have it as a shared component...

Re Kramiq: i didn't to be honest i'll have to find main {} somewhere and plaster this subroutine call at the beginning. Let's see what this does.

Re Bplaa.yai: a separate libxul.so would be nice for space concerns, however, expect that libxul.so will be relatively closely tied to the firefox version, so i don't think it would be wise to introduce a separate libxul.so and yet another dependency version headache. Let's get it running first and packaged.

Okay, here are my changes:

First, get firefox 3.0.10 from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.0.10/source/firefox-3.0.10-source.tar.bz2Then, make sure you have the basic gtk2 environment and build environment installed: neko_glib, neko_gtk, neko_glitz, neko_zlib, neko_idl, neko_idn, neko_freetype2, neko_zip, neko_python, neko_perl, neko_pango, neko_libxrender, neko_libxml2, neko_libtool, neko_make, neko_tar, neko_iconv, neko_expat, neko_cairo, neko_png, neko_atkThat should cover most of it.Unpack the tarball and you get a directory called mozilla/

Now get the patches:irix.patch which is a complete rollup of mine and Jimis' patches, excluding some gcc-ism'sidl.patch which is a pregenerated header file fix during a make crash mid-compile. UglyMutha, but does the trick..mozconfig which has all the environment plus basic mozilla configure flags.

Before patching the source with irix.patch, look at three absolute path header file includes, they start with "/work/everdij/firefox/mozilla", please change those where your mozilla build environment lives. This i need to fix in some makefiles.

Okay, put .mozconfig in mozilla/ directory, patch the source with patch -p0 < irix.patch and in that directory start the build with gmake -f client.mk build >& log & It will autostart ./configure before the actual source compile.

On my dual R12K@270MHz 1024MB O200 rig the build takes about 3 hours and 50 minutes, after it will bomb out at 3 errors in "nsAnnotationService.cpp". Apply the idl.patch with patch -p0 < idl.patch and continue the make with gmake -f client.mk build >& log2 &After another 50 minutes the firefox binary is built and installed in "mozilla/dist/bin/firefox-bin". If you want to run the binary directly, go to "mozilla/dist/bin" and type ./run-mozilla.sh ./firefox and be greeted with the bus error. Lazy people can just set the shared directory linker env variable with setenv LD_LIBRARY_PATH mozilla/dist/bin and type firefox directly (also very handy for the numerous test binaries beginning with "Test*"

So now you know. Good luck to the people that want to help me with this. If you want to debug the binary just --enable-debug and --disable optimization in .mozconfig. Sometimes it helps to debug with a static binary (200mb!!!) , so here's my static .mozconfig

I will just continue undeterred with this port, stubborn bastard as i am. Cheerio!

I appreciate your looking into it, but it still fails with the same error for me; I must have something fundamentally wrong with my build environment (at least as far as Firefox 3 goes). I'm at a loss as to what it could be. Thinking it may be parallel gmake related, I tried both with and without 'mk_add_options MOZ_MAKE_FLAGS="-j5"' (the difference in build times is astounding) but it made no difference either way.

nekonoko wrote:I appreciate your looking into it, but it still fails with the same error for me; I must have something fundamentally wrong with my build environment (at least as far as Firefox 3 goes). I'm at a loss as to what it could be. Thinking it may be parallel gmake related, I tried both with and without 'mk_add_options MOZ_MAKE_FLAGS="-j5"' (the difference in build times is astounding) but it made no difference either way.

I would appreciate if someone could come over here and kick me hard in various places. I found out that i forgot a patch:

Mea culpa, sorry sorry. I blame the ridiculous length of the patch, it's so easy to miss a quick patch.

I'll do some more digging in the coming days. Sofar i found out that there is an ns_ASSERTION being triggered in nsXPCOMStrings.cpp where for example nsStringContainer_base (12 bytes) is smaller than their content nsString (16 bytes). Aha, this can cause the alignment errors. Unfortunately, i failed in implementing sysmips() in mozilla/browser/app/nsBrowserApp.cpp, i'm probably overlooking something.

Thanks for pointing me where the makeflag '-j5' should go. Yet another brainfart

dexter1 wrote:Mea culpa, sorry sorry. I blame the ridiculous length of the patch, it's so easy to miss a quick patch

No problem at all - was just a bit disappointed that it was looking like my build system wasn't up to the task. With that final patch I was able to compile successfully and am now sitting at the 'Bus error' upon attempting a run

Thanks for pointing me where the makeflag '-j5' should go. Yet another brainfart

That should drop your build times significantly - really handy while debugging. For example, with -j5 it takes my quad 700MHz Tezro about 40 minutes to build Firefox-3. I expect that quad O200 you just unearthed will be able to finish a complete build within a couple hours.

Still trodding along, now doing patches for 3.0.11. Unfortunately i am encountering health problems again, as my neurologist instructed me to stop medication and symptoms are reappearing, so this is going to progress slowly.

Good news is that the two stage compile is gone. Everything can be compiled using a single patch and in one go, that took me some time. i also had a look at 3.5 and it already complained about Pango not being version 0.14 or higher, so this probably means that 3.5 is still not going to happen soon, though it looks like the code has been extensively rewritten (and hopefully cleaned up)

The only big problems remaining are the assert errors about stringcontainers. i've already fixed a va_copy oops and am now progressing with cvd through the binary (threads, aarrgghh)