firefox3 build fails on alpha

[Anton Shterenlikht]

On Mon, Aug 18, 2008 at 11:39:18AM +0200, Bernd Walter wrote:
> On Mon, Aug 18, 2008 at 09:37:12AM +0100, Anton Shterenlikht wrote:
> > On Sat, Aug 16, 2008 at 06:18:20PM +0200, Bernd Walter wrote:
> > > On Sat, Aug 02, 2008 at 05:01:23PM +0000, Christian Weisgerber wrote:
> > > > Anton Shterenlikht <mexas at bristol.ac.uk> wrote:
> > > > 
> > > > > I'm happy to test firefox3 on alpha, but need to learn about pathes.
> > > > > 
> > > > > In this particular case it seems that (at least) 2 files
> > > > > are missing from the distribution:
> > > > > 
> > > > > 	xptcinvoke_freebsd_alpha.cpp
> > > > > 	xptcstubs_freebsd_alpha.cpp
> > > > 
> > > > Yes.  These need to be created.
> > > > 
> > > > You have stumbled on a dirty secret:  the Mozilla family programs
> > > > rely on a part that must be ported at the assembly(!) language level
> > > > to each processor/compiler/(operating system) combination.
> > > > 
> > > > > I think that whoever created the tar file simply forgot to add the freebsd
> > > > > files.
> > > > 
> > > > No, somebody needs to write them.
> > > 
> > > I wrote them a few years back for mozilla and they were part of the port.
> > > Don't know what happened in the meantime, because since alpha support is
> > > removed I stopped spending time into it.
> > > The whole xptcinvoke thing is completely breandead anyway.
> > > The intention was to have a portable interfacing to modules, but in fact
> > > they just read the C++ vtable using assembly, which the compiler can do
> > > without any help.
> > > The assembly calling functions need to know the compiler specific
> > > vtable and not a fixed self defined, which is not what I expected to see.
> > > It took me several days to understand that they want something senseless.
> > 
> > Anyway, I seem to have fixed this. The build now passes this stage but
> > fails at another. The mozilla developers 'don't know' how to fix it, and
> > apparently lost the interest.
> > 
> > Anybody here cares to comment? Something to do with incorrect alignment.
> 
> The real bug is that they cast pointers of completely different types.
> You can work around by increasing the alignemnt requirement of
> PLDHashEntryHdr's type, so the compiler knows that.

Could you please elaborate on this?

I see in pldhash.h:

	typedef PRUint32                PLDHashNumber;

	struct PLDHashEntryHdr {
		PLDHashNumber       keyHash;
	       /* every entry must begin like this */
	};

I also see in ../../nsprpub/pr/include/prtypes.h

/************************************************************************
** TYPES:       PRUint32
**              PRInt32
** DESCRIPTION:
**  The int32 types are known to be 32 bits each.
************************************************************************/
#if PR_BYTES_PER_INT == 4
typedef unsigned int PRUint32;
typedef int PRInt32;
#define PR_INT32(x)  x
#define PR_UINT32(x) x ## U
#elif PR_BYTES_PER_LONG == 4
typedef unsigned long PRUint32;
typedef long PRInt32;
#define PR_INT32(x)  x ## L
#define PR_UINT32(x) x ## UL
#else
#error No suitable type for PRInt32/PRUint32
#endif

but I cannot see where PR_BYTES_PER_xxx are defined.
I think on alpha unsigned int should be 32 bit, it that correct?
Shall I try to redefine PRUint32 to 32 bit for certain?

thanks
anton


thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 928 8233 
Fax: +44 (0)117 929 4423