Closed Bug 567092 Opened 14 years ago Closed 14 years ago

Errors seen while building: nsFrame::operator delete in nsForms.h

Categories

(Thunderbird :: Build Config, defect)

Product:
Thunderbird
Component:
Build Config
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: swsnyder, Unassigned)

Details

Building with GCC 4.4.3 on fully-updated Fedora 12 / x86_64.

When building TB v3.1 RC1 many errors are seen of this nature:

~/comm-1.9.2/mozilla/layout/forms/../generic/nsFrame.h: In function 'nsIFrame* NS_NewGfxCheckboxControlFrame(nsIPresShell*, nsStyleContext*)':
~/comm-1.9.2/mozilla/layout/forms/../generic/nsFrame.h:171: error: 'static void nsFrame::operator delete(void*, size_t)' is protected
~/comm-1.9.2/mozilla/layout/forms/nsGfxCheckboxControlFrame.cpp:105: error: within this context

I get 14 of these errors before the overall build fails.  The C++ source files are different in each case, but the reference to line 171 of file nsFrame.h is always the same.

Full example:
c++ -o nsGfxCheckboxControlFrame.o -c -I../../dist/system_wrappers -include /home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DMOZ_THUNDERBIRD=1 -DOSTYPE=\"Linux2.6.32.12-115.fc12\" -DOSARCH=Linux -D_IMPL_NS_LAYOUT -I/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../base -I/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../generic -I/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../xul/base/src -I/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../../content/base/src -I/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../../content/html/content/src  -I/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms -I. -I../../dist/include -I../../dist/include/nsprpub  -I/usr/include/nspr4 -I/usr/include/nss3 -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -march=native -msse4.1 -momit-leaf-frame-pointer   -DMOZILLA_CLIENT -include ../../mozilla-config.h -Wp,-MD,.deps/nsGfxCheckboxControlFrame.pp /home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/nsGfxCheckboxControlFrame.cpp
/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../generic/nsFrame.h: In function 'nsIFrame* NS_NewGfxCheckboxControlFrame(nsIPresShell*, nsStyleContext*)':
/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/../generic/nsFrame.h:171: error: 'static void nsFrame::operator delete(void*, size_t)' is protected
/home/steve/rpmbuild/BUILD/thunderbird-3.1rc1/comm-1.9.2/mozilla/layout/forms/nsGfxCheckboxControlFrame.cpp:105: error: within this context
gmake[6]: *** [nsGfxCheckboxControlFrame.o] Error 1

Firefox v3.6.4, also built upon Gecko v1.9.2.4, builds correctly, while TB v3.1 RC1 does not.
Can you attach the mozconfig you are using for building please?

Although we included a few changes on top of 1.9.2.4, we didn't touch those files, and our own 64-bit builder that is currently doing test builds is working fine.

So I'm not quite sure what is going on here.
This is the mozconfig in use.  It is unchanged (for better or worse) from Fedora's TB v3.0.4 config.

mk_add_options MOZ_CO_PROJECT=mail
ac_add_options --enable-application=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb/
mk_add_options AUTOCONF=autoconf-2.13

#ac_add_options --with-system-png

ac_add_options --prefix="$PREFIX"
ac_add_options --libdir="$LIBDIR"
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-pthreads
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-installer
ac_add_options --enable-optimize="$RPM_OPT_FLAGS"
ac_add_options --enable-xinerama
ac_add_options --enable-default-toolkit=cairo-gtk2                                                                        
ac_add_options --disable-xprint                                                                                           
ac_add_options --disable-strip                                                                                            
ac_add_options --disable-install-strip
ac_add_options --enable-pango
ac_add_options --enable-system-cairo
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-system-hunspell
ac_add_options --disable-crashreporter

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

I also tried it --without system NSPR & NSS.  Didn't seem to make any difference.
(In reply to comment #3)
> mk_add_options MOZ_CO_PROJECT=mail

(side note) This flag is no longer necessary now we're in hg

Two thoughts:

ac_add_options --enable-optimize="$RPM_OPT_FLAGS"

As an experiment try dropping the ="$RPM_OPT_FLAGS" bit and just use the defaults that we provide.


Alternately, I would suggest you try a more basic mozconfig as an experiment, e.g.

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-debug
ac_add_options --enable-application=mail
ac_add_options --disable-debug
ac_add_options --enable-optimize

and see if that builds. If it does, then we can narrow it down to one of the options, if it doesn't then we can potentially assume its a complier fault.


I'm guessing a bit here, but narrowing down the problem area should help.
Using the default opt flags fixed it.

FYI, this is what $RPM_OPT_FLAGS resolves to:

-Os -g -pipe  -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -march=native -msse4.1 -momit-leaf-frame-pointer

I'm going to play with these options until I find out where the problem is.
The problem was resolved by removing that -fexceptions switch from Fedora's RPM_OPT_FLAGS definition.

Sorry to bother everyone.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
(In reply to comment #6)
> The problem was resolved by removing that -fexceptions switch from Fedora's
> RPM_OPT_FLAGS definition.
> 
> Sorry to bother everyone.

No problem. Glad you found the issue.
You need to log in before you can comment on or make changes to this bug.