SGI: Development

I decided to take a break from porting GCC4.80 and take a look at why Firefox3.5 not working. I didn't some testing of the libraries in found faults in GTK>=2.6 and a faulty DBUS library currently in Neko beta. I have a fixed GTK2.10.14 with cairo 1.8 now. I working on DBUS now and hopefully will have something working later today.
I did a quick check to see if Firefox 3.5 would compile OK and quickly came to a conclusion I will need a patch to build it with GCC. I was wondering does anyone have one for Firefox 3.5 or later?
I didn't try compiling Firefox 3.5 under Mipspro. Does anyone know if it will build under Mipspro 7.4m without a patch?

My attempts with Firefox 3 series was with version 3.0.15. Yes, it does need a substantial amount of patches in the MIPSPro build, at least for that version. I haven't attempted a gcc build yet, but check the search feature. There are some posts pertaining 3.5.5 builds by PymbleSoftware, see viewtopic.php?f=15&t=16725898

rosehillbob wrote: I didn't some testing of the libraries in found faults in GTK>=2.6 and a faulty DBUS library currently in Neko beta. I have a fixed GTK2.10.14 with cairo 1.8 now.

Did you try the file handling features ? With the Firefox 3.0.19 in nekoware, I was able to build gtk 2 up to 2.10.16 (iirc) without too many problems, but the file handling went to hell at about x.12. Firefox would run fine but if you tried to download or save a file, kerblammo.

I decided to use gtk2.10.14 to do testing (yes I did test/fix a file handling bug) simply because Firefox3.5 requires gtk >=gtk2.10. I decided not try any later version simply because firefox3.5 must have gone under a lot of testing with gtk2.10 before release. The other library I need to test is DBUS. The use of DBUS was added in firefox3.5 and later. Currently every version of DBUS fails its own validation suite whether compiled with gcc or mipspro. The version in Nekoware also fails the validation suite so I assume the builder didn't test it. The Library is used for communication between process so the predicted result right now is firefox on startup would display a blank page but the moment it tries to render a page over the internet and launches a background process to prefetch DNS lookups it will core dump. This is my prediction even through I have never seen Firefox3.5 on IRIX and from what I read in post's that prediction is correct.
I hope to have a debugged DBUS in a couple of days and hopefully someone will send me a diff file to compile firefox3.5 or 3.6 with either gcc or mipspro or this will be a wasted effort.

Check with diegel - I believe he was working on firefox 3.5 not too long ago. He also built the 3.0.19 version in Nekoware as far as I recall.

Woops, I was mistooken It's gtk 2. 12 .16 that's easy to get to. After that, it wasn't too hard to get through the 18's, as I remember.

Then there was a big hurdle. Maybe at 2.14.0 ? Somewhere right around there.

Anyway, gtk 2.12.12 even passes the tests, then up to 2.12.16 is also easy but the file handling goes kerput, then up to 2.12.18 had a couple more hangups but still pretty simple. There were some improvements and fixes mixed in with the goofiness. In fact, I was running 2.12.2?-something, I think. It was noticeably better except had to be careful to not download any file in Firefox or the world came to an end. So if you have a little spare time ....

rosehillbob wrote: firefox3.5 must have gone under a lot of testing ...

Umm, yeah. You might want to revisit that assumption. In fact, I'm kinda curious about how you got "testing" and "firefox" into the same sentence ?

That's great news. I am currently at work and don't have access to my build system. I will post my current ff3.5 build config later this day. I will also have a look at dbus. By the way, it is quite common that nekoware packages do not pass their test suite.

dexter1 wrote: My attempts with Firefox 3 series was with version 3.0.15.

You have been very close to a working ff3. The only change I had to do is to add the following line to .mozconfig to avoid the bus error:



If you want to see you ff3.0.15 running you can try this.

Which version of firefox3.5 are you using for the build? I have 3.5.09 and with gcc it stops with message cc1 error '-march=-mips2' not compatible with the slected ABI. If try mipsPro7.4m i get 'as unrecognized option -_ASM'.
I gather from the above post 'ac_add_options --disable-safe-browsing' is a minor change to make things build...that is not what I am seeing here.
Note I did try a simple patch and got past the compiling this particular file with gcc only hit another road block (failed to link NSPR), made a second patch to links NPSR only to find a link problem in JS and so on. The rate I am going I will have to make dozen's of source code changes to just get it to build then comes the fun part of debugging it.
Is that your experience with 3.5?

I just notice something interesting on the Mozilla site concerning the requirements to run Firefox version 22. It states for the Linux platform DBUS isn't required to run but is listed as a "optional library to increase performance". I next downloaded the Firefox source code for 22 and found in the configure program the check for DBUS is still there! Hmmm... so DBUS is required to compile but not required to run (at least for the Linux case) so this must mean DBUS is loaded via DLOPEN! If that is the case and I am pretty sure IRIX supports dlopen as well so maybe a test of possible DBUS problems is to simply uninstall DBUS after you build Firefox3.5 and see if Firefox3.5 starts up without link errors. If it does well that is one way to see if DBUS is at fault!

I am working with ff3.5.19. I build it with dbus disabled. Attached you find my current patch. This is my build environment:



Here comes the .mozconfig:



The ff3.0.19 build instructions are still working:

Build instructions:

Get the source code from:

ftp://ftp.mozilla.org/pub/firefox/relea ... ce.tar.bz2

extract it and apply the attached patch.

Get a current version of sqlite3:

http://www.sqlite.org/download.html

Copy sqlite3.c and sqlite3.h from current sqlite3 to mozilla/db/sqlite3/src

There may be a problem with signlib during build. Make sure there
are no shared libs in /usr/nekoware/lib/firefox-3.0.19 during build instead
you must have a firefox2 or seamonkey1 lib directory in your LIB search path.
Otherwise signlib may coredump.

set the environment and start the build:

gmake -f client.mk build

There is one assembler file in libfreebl you have to compile manually with gcc3.

cd security/nss/lib/freebl
gcc -x assembler-with-cpp -o /work/mozilla-1.9.1/ff-deb-static/nss/freebl/IRIX_SINGLE_SHLIB/mpi_mips.o -Wp,-P -Wp,-traditional-cpp -c mpi/mpi_mips.s

Yesterday i got my main O200 fileserver back online after it shut down two years ago. i have located various build directories, one of which was firefox 3.5.5 with MIPSPro 7.4 and nekoware from 2009
I'll share this firefox 3.5.5 work in progress build as well. I haven't done much since 2010, but there is one more O200 i have to revive that i think has firefox 3.0.19 build directory with the bus error.

mozconfig


Two patch files, one for the firefox main source one for the XPTC/NS bruhaha



There are other hurdles on the road, but this should get a MIPSPro build going

I think the current problem is still in xpcom. This is possibly a start to find out more: https://bugzilla.mozilla.org/show_bug.cgi?id=482759

I downloaded ff3.5.19 and diegel's patch and attempted a build. The build stopped at xpcom saying unable to build a stubsdef... file. I found the missing file in dexter1's xptcall patch. I added the file only to find it the IRIX assembly files in xptcall wouldn't assemble without error. The fault ended up being gcc was calling the gnu assembler and the gnu assembler was choking on the syntax. The solution was to modify Makefile.in to use the system assembler instead. I also modifed Makefile.in in security/nss/lib/freebl as well so the build continues to the end without interruption. I was now able to attempt to run firefox. What happens is it shoots a bunch of messages about registering various components then display several assertion failed messages and does a graceful shutdown (it doesn't crash with a bus error or dump core) instead display memory stats while shutting down. I did check the above link since the missing file is related to the above bug report link. Bugzilla resolved the problem with the change in GCC 3.0 abi by a patch which reads the stub file and generates the necessary C++ decoration on the fly. Diegel's patch uses a 'hand modified stubs file' todo the same thing. This file was missing in diegel's patch so I used the one from dexters patch file which may or may not be correct. I plan to implement the change tonight listed in bugzilla tonight to see if it corrects the problem...Building takes hours whenever a change is made. I calculated using an Onyx2 added $2 to my electric bill so far so I may have to pass the hat if I need to do a bunch of debugging!

rosehillbob wrote: I found the missing file in dexter1's xptcall patch.

Sorry, this file was indeed missing in my patch but it's the same file I use for ff3 and also ff3.5. I am glad to read that you are able to build it now. If you are starting an optimized build it will take at least twice the time to build. There was an attempt to port ff10 some time ago, he stopped this project after he was unable to link a huge libmoz because of Irix ld limitations. If you are interested in this work, I can provide this for you. If I can support your work please let me know.

I examined the patch in the posted link and the way it decorates the function although coded although different has the same result as the current patch. The test "testxpcinvoke" works correctly so XPCOM is OK. The next thing I tried was to enable the use of DBUS which is the default build. I expected the code to fault in DBUS but before it did twice as many components successfully registered(and three times as fast) as compared to when the code is compiled with DBUS disabled. It looks like the next step is correct the DBUS library before go any further with debugging Firefox3.5.

This is possibly helpful for you: I tried the ff3.1 alpha versions and they also have the same problem like 3.5. The main difference between 3.0 and 3.1 is the new javascript engine. So I guess the problem is related with this.

I examined the link above and the changes to xpcom basically do the same thing as the xpstubsdef file. The test program for xpcinvoke executes correctly therefore xptcall isn't where the fault lies. I did another check and this time built it with DBUS which is the default. Now the DBUS in Nekoware is faulty - fails it own tests with core dump - but with it enabled firefox3.5 registers three times as many components including ones that failed before (Firefox stops with DBUS dumping core). I will now look into DBUS and do some low level debugging to get a IRIX port working.

I have been doing some looking into DBUS I noticed a problem with g_spawn_async (from GLIB). I also did some research and found out with the introduction of libxul with FF2.0 Mozilla is relying less and less on NSPR and more on GLIB in the UNIX ports. Glib has multiple variations of g_spawn and depending on which ones Firefox or DBUS are using the outcomes will be different. I suspect Firefox3.5 without DBUS enabled is using GLIB to spawn processes and DBUS is using GLIB as well but there is more than one function call. Remember the fault of Firefox3.5 without DBUS enabled is it fails to start new a process ( a listener) and times out with an error unable to communicate to the listener. Well to get DBUS to work I have to get a proper working GLIB which may solve some other problems. Firefox with 'tests_enabled' builds a whole host of test programs. The test programs associated with inter process communication all fail . I haven't tried out the javascript test programs yet...I think more of firefox must work first.

rosehillbob wrote: Well to get DBUS to work I have to get a proper working GLIB which may solve some other problems.

From my experience you have to go back to glib-2.20.5 to find a glib that passes all tests. If you do so, you have to rebuild all glib dependencies.I did this already for debugging, but I never tried to use dbus.