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 firstname.lastname@example.org), 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.
Please try that patch and report back with r= love. /be
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++.
the 2nd patch allows xpcom to link on osx. what say you?
Sorry, I didn't attach the (hacked, cuz I have other changes) patch for nsFastLoadFile.cpp. pink did it right -- email@example.com, 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?
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