93479 - link errors after fastload landing

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A bunch of seemingly related linker errors started after the fastload landing.

On the HP 10.20 tinderbox, a runtime error in the dynamic linker:

/usr/lib/dld.sl: Unresolved symbol: static_dummy (data)  from
/builds/tinderbox/SeaMonkey/HP-UX_B.10.20_Clobber/mozilla/dist/bin/libxpcom.sl


On gcc on some versions of RedHat 7.0, mostly with older compiler versions (see
n.p.m.builds post by [e-mail]), a compile-time link error:

../../../dist/bin/libxpcom.so: undefined reference to `dummy.977'


From gcc on Mac OS X (the most helpful), another compile-time link error:
[14:20:40] <pink_osx> ld: common symbols not allowed with MH_DYLIB output format
[14:20:42] <pink_osx> nsFastLoadFile.o definition of common
__Q320nsFastLoadFileReader16nsFastLoadFooter54GetID__CQ220nsFastLoadFileReader16nsFastLoadFooterUi.0.dummy
(size 16)
[14:20:45] <pink_osx> nsFastLoadFile.o definition of common
__Q320nsFastLoadFileReader16nsFastLoadFooter68GetSharpObjectEntry__CQ220nsFastLoadFileReader16nsFastLoadFooterUi.0.dummy
(size 16)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

[14:25:27] <Pike> dbaron: nsFastLoadFile.h:            static nsID dummy;

Comment 2

[Mike Pinkerton (not reading bugmail)]

this blocks mach-o osx development, upping severity.

Comment 3

[Brendan Eich [:brendan]]

Attachment: proposed workaround

Comment 4

[Brendan Eich [:brendan]]

Please try that patch and report back with r= love.

/be

Comment 5

[Mike Pinkerton (not reading bugmail)]

the new error, with the above patch applied is:

ld: Undefined symbols:
__Q220nsFastLoadFileReader16nsFastLoadFooter.gDummyID
__Q220nsFastLoadFileReader16nsFastLoadFooter.gDummySharpObje
ctEntry
/usr/bin/libtool: internal link edit command failed

Comment 6

[Mike Pinkerton (not reading bugmail)]

don't you need to define the storage for those static vars outside the class 
decl? that's how it's usually done with static members in c++. 

Comment 7

[Mike Pinkerton (not reading bugmail)]

Attachment: patch that links on macosx

Comment 8

[Mike Pinkerton (not reading bugmail)]

the 2nd patch allows xpcom to link on osx. what say you?

Comment 9

[Brendan Eich [:brendan]]

Sorry, I didn't attach the (hacked, cuz I have other changes) patch for
nsFastLoadFile.cpp.  pink did it right -- sr=[e-mail], get this in to
unblock.

/be

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Probably those static members should be private (unless Brendan disagrees), but
otherwise r=dbaron.

Function-scope statics in inline functions seem odd anyway.  What are they
supposed to do?  Should we add a comment to the C++ portability guidelines?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Doh!  I didn't look at Brendan's original patch.  But maybe they should be
private anyway?

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

r=dbaron

Comment 13

[Brendan Eich [:brendan]]

These are struct members, the struct is nested in a protected: section of a
class, so I am comfortable with the degree of nudity.

/be

Comment 14

[Mike Pinkerton (not reading bugmail)]

checked in.