SPARC v9 Firefox build

Well, after succeeding in building a v8plusb architecure version of Firefox 1.0, I applied myself to the challenge of building a v9 version. It started off swimmingly after I'd discovered a little bug I'd introduced in a Makefile whilst messing with trying to get a v8plusb version to work. Then, I got an error from the assembler when building a SPARC assembly file. I need to specify the arch in ASFLAGS too...

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:

/usr/lib/libgconf-2.so
/usr/lib/libORBit-2.so
/usr/lib/liblinc.so
/usr/lib/libgnomevfs-2.so
/usr/lib/libbonobo-activation.so
/usr/lib/libgnome-2.so
/usr/lib/libbonobo-2.so

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

Comments:

I don't think a 64bit Firefox will get you anything. Well you might need more memory to run Firefox and it'll be slower, but otherwise it'll be fine :)

Posted by Azeem Jiva on December 10, 2004 at 09:48 AM GMT #

Post a Comment:
Comments are closed for this entry.
About

tdw

Search

Top Tags
Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today