206726 - Using nsTHashtable breaks Mac build

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Benjamin Smedberg]

configure.in defines CFLAGS and CXXFLAGS with -fno-common. This is breaking my
hashtable templates when they are included in multiple files. The checkin from
bug 202080 broke mac with this error:

c++  -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-long-long
-fpascal-strings -traditional-cpp -fno-common -fshort-wchar
-I/Developer/Headers/FlatCarbon -F/System/Library/Frameworks -pipe  -DNDEBUG
-DTRIMMED -O -DDEPENDENT_LIBS="\"libgkgfx.dylib\", \"libxpcom.dylib\",
\"libplds4.dylib\", \"libplc4.dylib\", \"libnspr4.dylib\",
\"libpthread.dylib\"," -fPIC -arch ppc -o libaccessibility.dylib 
nsAccessibilityFactory.o  nsAccessNode.o nsDocAccessible.o
nsOuterDocAccessible.o nsAccessibilityAtoms.o nsAccessibilityService.o
nsAccessible.o nsAccessibleTreeWalker.o nsBaseWidgetAccessible.o
nsFormControlAccessible.o nsRootAccessible.o nsCaretAccessible.o
nsTextAccessible.o nsHTMLAreaAccessible.o nsHTMLFormControlAccessible.o
nsHTMLImageAccessible.o nsHTMLLinkAccessible.o nsHTMLSelectAccessible.o
nsHTMLTableAccessible.o nsHTMLTextAccessible.o nsAccessNodeWrap.o
nsAccessibleWrap.o nsDocAccessibleWrap.o!
  nsRootAcce
ssibleWrap.o nsXULColorPickerAccessible.o nsXULFormControlAccessible.o
nsXULMenuAccessible.o nsXULSelectAccessible.o nsXULTabAccessible.o
nsXULTextAccessible.o nsXULTreeAccessible.o     -L../../dist/bin
-L../../dist/lib -lgkgfx -L../../dist/bin -lxpcom -L../../dist/bin
-L/builds/tinderbox/SeaMonkey/Darwin_6.6_Depend/mozilla/dist/lib -lplds4 -lplc4
-lnspr4 -lpthread    -bundle -lm    
ld: multiple definitions of symbol
_ZZN12nsTHashtableI17nsBaseHashtableETI13nsVoidHashKey8nsCOMPtrI13nsIAccessNodeEEE4InitEjE4sOps
nsAccessNode.o definition of
_ZZN12nsTHashtableI17nsBaseHashtableETI13nsVoidHashKey8nsCOMPtrI13nsIAccessNodeEEE4InitEjE4sOps
in section (__DATA,__data)
nsDocAccessible.o definition of
_ZZN12nsTHashtableI17nsBaseHashtableETI13nsVoidHashKey8nsCOMPtrI13nsIAccessNodeEEE4InitEjE4sOps
in section (__DATA,__data)

I can make a patch altering those two lines, but I don't have a mac to test it.
 I looked, and bryner seems to have fixed these sorts of problems in the past,
so I've given the bug to him... if that's not right, let me know who is the
right person for this.

Comment 1

[Benjamin Smedberg]

Attachment: remove -fno-common for OSX

Comment 2

[Aaron Leventhal]

Benjamin, I'd test the patch on my Mac, but the old patch from bug 202080
already linked okay on it.

Comment 3

[Brian Ryner (not reading)]

I played with removing this a couple of days ago, but put it on hold because I
didn't see any compelling benefit.  What I did find is that just turning off the
flag breaks the build, because it causes some of our code to generate common
symbols, which are disallowed in .dylibs.  (specifically, dylibs where
-single_module is not used)

How did you determine that -fno-common is causing the problem if you don't have
a mac to test on?

Comment 4

[Brian Ryner (not reading)]

Comment on attachment 123972 [details] [diff] [review]
remove -fno-common for OSX

minusing since I think this will break the build.

Comment 5

[Brian Ryner (not reading)]

Updating summary.

I believe this is a compiler bug, which is fixed in the latest (December 2002)
developer tools release. Quoting from the list of bugs fixed in this release:

Radar 3010993, 3011026, 3078492
    The compiler now handles static variables in function templates properly.

Unfortunately, if we want to continue to support building on MacOS 10.1.x, we
can't require the latest dev tools.  Would it be possible to make |sOps| not be
a static variable in nsTHashtable::Init()?  Maybe make it a class variable? 
(I'm confirming now that the patch builds ok with the december tools)

Comment 6

[Aaron Leventhal]

That would explain why it works on my PowerBook G4, which I got after December.

Comment 7

[Brian Ryner (not reading)]

The patch definitely builds for me as-is with the December 2002 tools.

Comment 8

[Benjamin Smedberg]

alecf: now what? How awful is adding a PLDHashOps to each class (36 bytes)?

bryner: this sounds like a compiler-workaround #ifdef may be necessary. Is there
a way to just #ifdef the older mac compiler?

Comment 9

[Alec Flett]

if this is a compiler bug and is fixed by the Dec2002 build tools, I see no
reason to try to fix it.. we just need to update the Mac build page to tell
people to get the new tools...

Comment 10

[Brian Ryner (not reading)]

alecf: That's the plan.  We're working on getting the tinderboxes and nightly
build machines updated.

Comment 11

[Brian Ryner (not reading)]

All of the build machines have been updated.  I'll resolve this as fixed; build
instructions will be updated soon to show the new tools requirement.