link errors after fastload landing

RESOLVED FIXED in mozilla0.9.4

Status

()

Core
XPCOM
P1
blocker
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: dbaron, Assigned: brendan)

Tracking

Trunk
mozilla0.9.4
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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 glazman@netscape.com), 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)
[14:25:27] <Pike> dbaron: nsFastLoadFile.h:            static nsID dummy;
this blocks mach-o osx development, upping severity.
Blocks: 75653
Severity: normal → blocker
(Assignee)

Comment 3

17 years ago
Created attachment 44595 [details] [diff] [review]
proposed workaround
(Assignee)

Comment 4

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

/be
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.4
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
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++. 
Created attachment 44605 [details] [diff] [review]
patch that links on macosx
the 2nd patch allows xpcom to link on osx. what say you?
(Assignee)

Comment 9

17 years ago
Sorry, I didn't attach the (hacked, cuz I have other changes) patch for
nsFastLoadFile.cpp.  pink did it right -- sr=brendan@mozilla.org, get this in to
unblock.

/be
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?
Doh!  I didn't look at Brendan's original patch.  But maybe they should be
private anyway?
r=dbaron
(Assignee)

Comment 13

17 years ago
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
checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.