firefox3 build fails on alpha
Anton Shterenlikht
mexas at bristol.ac.uk
Mon Aug 18 08:37:25 UTC 2008
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.
Please see below the bugzilla thread.
https://bugzilla.mozilla.org/show_bug.cgi?id=449373
"I'm building firefox3.0.1 on FreeBSD-6.3-stable Alpha.
I get this error message:
gmake[5]: Entering directory
`/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src'
nsCookieService.cpp
c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
-DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX
-D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES
-DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I.
-I../../../dist/include/xpcom -I../../../dist/include/string
-I../../../dist/include/pref -I../../../dist/include/storage
-I../../../dist/include -I../../../dist/include/necko
-I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include
-I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include
-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing
-fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror
-I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include
../../../mozilla-config.h nsCookieService.cpp
../../../dist/include/xpcom/nsTHashtable.h: In static member function `static
PRBool nsTHashtable<EntryType>::s_MatchEntry(PLDHashTable*, const
PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]':
../../../dist/include/xpcom/nsTHashtable.h:335: instantiated from `PRBool
nsTHashtable<EntryType>::Init(PRUint32) [with EntryType = nsCookieEntry]'
nsCookieService.cpp:418: instantiated from here
../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const
PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of
target type
gmake[5]: *** [nsCookieService.o] Error 1
Reproducible: Always
Steps to Reproduce:
1. get FreeBSD-6.3-Alpha
2. cd /usr/ports/www/firefox3
3. make
Actual Results:
../../../dist/include/xpcom/nsTHashtable.h:368: warning: cast from `const
PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of
target type
I believe this warning indicates a problem that leads to failure of compilation
of nsCookieService.cpp
Comment #1 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-06 07:57:51 PDT
This is an interesting bug, and it may be "real" in some sense. nsTHashtable is
a wrapper around the pldhash code, which places entries (which begin with or
are derived from PLDHashEntryHdr) in a contiguous array. It uses sizeof(entry)
as the entry size, which may not be the same as the required alignment for the
entry type.
What is the required alignment of nsCookieEntry and PLDHashEntryHdr? Is there a
way for the compiler to tell us what the required alignment is? If so, we may
need to extend the entry size to the required alignment. In that case we "know"
that the PLDHashEntryHdr* is of the required alignment, and this cast should be
safe... then how do we tell the compiler that it's a safe cast?
In an private mail from Anton he says that this worked in FF2 but broke in FF3
because previously we were using NS_REINTERPRET_CAST and we're now using
reinterpret_cast<>(), but these should have been equivalent on any modern C++
compiler.
Also, it seems like this could be a static_cast instead of a reinterpret_cast,
since in nsTHashtable the entry types are always derivatives. I can provide a
patch to that effect to see if it helps.
Comment #2 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-06 09:09:44 PDT
Created an attachment (id=332545) [details]
nsTHashtable use static_cast and not reinterpret_cast, rev. 1
Anton, please try this patch and let me know whether it helps.
Comment #4 [reply] Anton Shterenlikht 2008-08-07 02:00:12 PDT
I saved the patch into
/usr/ports/www/firefox3/work/mozilla/xpcom/glue/ns/nsTHashtable.h.patch
Then I did
# patch < nsTHashtable.h.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/xpcom/glue/nsTHashtable.h b/xpcom/glue/nsTHashtable.h
|--- a/xpcom/glue/nsTHashtable.h
|+++ b/xpcom/glue/nsTHashtable.h
--------------------------
Patching file nsTHashtable.h using Plan A...
Hunk #1 succeeded at 157 (offset -6 lines).
Hunk #2 succeeded at 355 (offset -6 lines).
Hunk #3 succeeded at 365 (offset -6 lines).
Hunk #4 succeeded at 375 (offset -6 lines).
Hunk #5 succeeded at 387 (offset -6 lines).
Hunk #6 succeeded at 396 (offset -6 lines).
Hunk #7 succeeded at 408 (offset -6 lines).
Hmm... Ignoring the trailing garbage.
done
#
The error message is very similar, if not the same:
gmake[5]: Entering directory
`/usr/ports/www/firefox3/work/mozilla/netwerk/cookie/src'
nsCookieService.cpp
c++ -o nsCookieService.o -c -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
-DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX
-D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES
-DOSTYPE=\"FreeBSD6\" -DOSARCH=FreeBSD -DIMPL_NS_NET -I. -I.
-I../../../dist/include/xpcom -I../../../dist/include/string
-I../../../dist/include/pref -I../../../dist/include/storage
-I../../../dist/include -I../../../dist/include/necko
-I/usr/local/include/nspr -I/usr/include -I../../../dist/sdk/include
-I/usr/local/include -fPIC -I/usr/local/include -I/usr/local/include
-fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-long-long -O -pipe -mcpu=ev6 -mieee -O2 -fno-strict-aliasing
-fno-strict-aliasing -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O -Werror
-I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include
../../../mozilla-config.h nsCookieService.cpp
../../../dist/include/xpcom/nsTHashtable.h: In static member function `static
PRBool nsTHashtable<EntryType>::s_MatchEntry(PLDHashTable*, const
PLDHashEntryHdr*, const void*) [with EntryType = nsCookieEntry]':
../../../dist/include/xpcom/nsTHashtable.h:334: instantiated from `PRBool
nsTHashtable<EntryType>::Init(PRUint32) [with EntryType = nsCookieEntry]'
nsCookieService.cpp:418: instantiated from here
../../../dist/include/xpcom/nsTHashtable.h:367: warning: cast from `const
PLDHashEntryHdr*' to `const nsCookieEntry*' increases required alignment of
target type
gmake[5]: *** [nsCookieService.o] Error 1
thanks
anton
Comment #5 [reply] Anton Shterenlikht 2008-08-07 05:08:01 PDT
Also, in case it matters, the compiler versions are:
# gcc -v
Using built-in specs.
Configured with: FreeBSD/alpha system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
#
# gcc42 -v
Using built-in specs.
Target: alpha-portbld-freebsd6.3
Configured with: ./..//gcc-4.2-20080702/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.5
--with-gxx-include-dir=/usr/local/lib/gcc-4.2.5/include/c++/ --disable-libgcj
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc42
alpha-portbld-freebsd6.3
Thread model: posix
gcc version 4.2.5 20080702 (prerelease)
#
I believe freebsd3 port is being built with the system compiler, i.e. 3.4.6.
anton
Comment #6 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-07 05:27:34 PDT
In that case, I do not know how to fix this bug... I'm almost certain the error
is bogus, since we know that the PLDHashEntryHdr* is the correct alignment
(confirmed using sizeof()), but I don't know how to inform the compiler that
this cast should be allowed.
Comment #7 [reply] Mike Shaver 2008-08-07 05:42:08 PDT
How do you confirm alignment with sizeof?
Comment #8 [reply] Benjamin Smedberg [:bs] (bsmedberg) 2008-08-07 05:56:30 PDT
>From experiments, it seems that sizeof(struct) is always a multiple of the
necessary alignment for that struct.
The pldhash entry store is malloced (which has perfect alignment) and entries
are on sizeof(struct) boundaries within the allocation, so I believe that in
reality they are always correctly aligned.
Shaver says: "I guess you want to cast via void*"... which makes me sad! "
--
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
More information about the freebsd-alpha
mailing list