Most likely this bug is caused by newer GCC.

The problem is that

	mozilla/xpcom/reflect/src/xptcall/src/md/unix/xptcstubs_linux_alpha.cpp

defines STUB_ENTRY like this:

	#define STUB_ENTRY(n) \
	__asm__( \
	    "#### Stub"#n" ####\n" \
	".text\n\t" \
	    ".align 5\n\t" \
	    ".globl Stub"#n"__14nsXPTCStubBase\n\t" \
	    ".ent Stub"#n"__14nsXPTCStubBase\n" \
	"Stub"#n"__14nsXPTCStubBase:\n\t" \
	    ".frame $30,0,$26,0\n\t" \
	    "ldgp $29,0($27)\n" \
	"$Stub"#n"__14nsXPTCStubBase..ng:\n\t" \
	    ".prologue 1\n\t" \
	    "lda $1,"#n"\n\t" \
	    "br $31,$SharedStub..ng\n\t" \
	    ".end Stub"#n"__14nsXPTCStubBase" \
	    );

However, newer GCC apparently mangles C++ names differently.
Running nm on libxptcall.a shows that it expects symbols like

	_ZN14nsXPTCStubBase5Stub3Ev
	_ZN14nsXPTCStubBase6Stub10Ev
	_ZN14nsXPTCStubBase7Stub100Ev

So, the solution to the problem is to modify the STUBS_ENTRY macro.
Since I'm no CPP guru I fixed it like this:

191c191
< #define STUB_ENTRY(n) \
---
> #define STUB_ENTRY(n, m) \
196,198c196,198
<     ".globl Stub"#n"__14nsXPTCStubBase\n\t" \
<     ".ent Stub"#n"__14nsXPTCStubBase\n" \
< "Stub"#n"__14nsXPTCStubBase:\n\t" \
---
>     ".globl _ZN14nsXPTCStubBase"#m"Stub"#n"Ev\n\t" \
>     ".ent _ZN14nsXPTCStubBase"#m"Stub"#n"Ev\n" \
> "_ZN14nsXPTCStubBase"#m"Stub"#n"Ev:\n\t" \
201c201
< "$Stub"#n"__14nsXPTCStubBase..ng:\n\t" \
---
> "$_ZN14nsXPTCStubBase"#m"Stub"#n"Ev..ng:\n\t" \
205c205
<     ".end Stub"#n"__14nsXPTCStubBase" \
---
>     ".end _ZN14nsXPTCStubBase"#m"Stub"#n"Ev" \

I couldn't figure out how to extract length of n in CPP, so I added a new
parameter m.  This also requires patching

	mozilla/xpcom/reflect/xptcall/public/xptcstubsdef.inc

to add the lengths (5, 6 and 7) to all the STUBS_ENTRY calls.

Alternative is, if it's possible, to make STUBS_ENTRY define
an actual C++ function, like STUBS_SENTINEL.

With this, the build is now at least past the point where it last bombed.

  -- Arto