From owner-freebsd-alpha@FreeBSD.ORG Mon Aug 18 15:35:13 2008 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED1B106566C for ; Mon, 18 Aug 2008 15:35:13 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 36C408FC19 for ; Mon, 18 Aug 2008 15:35:13 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1KV6l9-000470-Pl; Mon, 18 Aug 2008 16:35:12 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1KV6l8-0000m2-Rg; Mon, 18 Aug 2008 16:35:07 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.2/8.14.2) with ESMTP id m7IFZ5BJ004935; Mon, 18 Aug 2008 16:35:05 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.2/8.14.2/Submit) id m7IFZ5UA004934; Mon, 18 Aug 2008 16:35:05 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Mon, 18 Aug 2008 16:35:04 +0100 From: Anton Shterenlikht To: ticso@cicely.de Message-ID: <20080818153504.GA4848@mech-cluster238.men.bris.ac.uk> References: <20080708120738.GA74833@mech-cluster238.men.bris.ac.uk> <20080712225929.GA22401@freebie.xs4all.nl> <20080731222442.GA35346@mech-cluster238.men.bris.ac.uk> <20080816161820.GG37139@cicely7.cicely.de> <20080818083712.GA1032@mech-cluster238.men.bris.ac.uk> <20080818093918.GE6331@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080818093918.GE6331@cicely7.cicely.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.4 X-Spam-Level: - Cc: freebsd-alpha@freebsd.org Subject: Re: firefox3 build fails on alpha X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 15:35:13 -0000 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 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