SPARC v9 Firefox build
By tdw on Dec 10, 2004
ASFLAGS=-xarch=v9b; export ASFLAGS
Got a bit further, then got some errors to do with casting anonymous pointers to unsigned ints (you naughty boys!). This works okay on a 32-bit architecture, but the 64-bit compiler rightly complains that you can't cast a 64-bit pointer to a 32-bit unsigned int. So, I had to add a little tweak to nsHttpConnectionMgr::OnMgsUpdateParam(...):
#ifdef __sparcv9 PRUint64 param2 = (PRUint64)param; #else PRUint32 param2 = PRUint32(param); #endif PRUint16 name = (PRUint32(param2) & 0xFFFF0000) >> 16; PRUint16 value = PRUint32(param2) & 0x0000FFFF;
The build carried on for a while from there and then fell over with another anonymous pointer to int cast. This time, the culprit was Glib's GPOINTER_TO_INT macro. It took me an age to discover that the include file which contains this declaration is not in a file in /usr/include/glib-2.0 as anticipated, but in /usr/lib/glib-2.0/include. However, I needed the sparcv9 version which was in /usr/lib/sparcv9/glib-2.0/include. Had to make a quick hack to the Makefile to add this file to the INCLUDES list - I'm not smart enough to figure out where in the complexity of auto-config it needs to go.
A few seconds more of build, then anouther failure in the same directory. This time we have nsDragService.cpp casting a GdkAtom to an int. GdkAtom is actually a pointer, so this was why it was failing. I'm not sure what the correct fix is here, but I assumed that Glib's GPOINTER_TO_INT() macro would do the trick, so i changed all of the offending casts to use that.
Restart the build, off for a cup of tea and do something else for a few minutes.
Alas, the anticpated downfall came when the build tried to glue all of the gtk code into a shared object. Unfortunately, the code references a number of GNOME libraries which don't have 64-bit counterparts on Solaris 9:
Short of downloading the source for each of these and building 64-bit versions, I'm not sure what I can do to rectify this one. I did check Blastwave, but they too only do 32-bit binaries for these libraries :(
I'm not defeated yet, but I don't expect that getting the above libraries as 64-bit objects will be the end of it