Attempting to link an XPCOM component on Mac OS X (x86, 10.4, gcc 4.0.1) gives the following error: g++ -DXP_UNIX -DXP_MACOSX -DNO_X11 -fpascal-strings -no-cpp-precomp -fno-common -Wall -ggdb -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fno-rtti -D__darwin__ -DXP_DARWIN -o pcenvStage/components/libDataCollector.dylib DataCollector.o DCModule.o CellMLToRDFTree.o MathMLInputServices.o TextRepScanner.o TextRepParse.tab.o -L. -L/Users/cmiss/Build/omniORB-4.0.7/lib -L/Users/cmiss/physiome_builds/trees/XPCORBA -L/Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/lib -L/Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/bin -l'xpcom' -l'nspr4' -l'plc4' -l'omniORB4' -l'omnithread' -l'xpcomglue_s' -l'xpcorba' -bundle -Wl,-executable_path,/Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/bin /usr/bin/ld: /Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/lib/libxpcomglue_s.a(nsCOMArray.o) malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__const_coal) from section (__TEXT,__text) relocation entry (3)) /usr/bin/ld: /Users/cmiss/physiome_builds/trees/mozilla_trunk/obj-i386-apple-darwin8.8.1/stablexr/dist/lib/libxpcomglue_s.a(nsCOMArray.o) malformed object, illegal reference for -dynamic code (reference to a coalesced section (__TEXT,__const_coal) from section (__TEXT,__text) relocation entry (7)) Looking into the relocation table with otool -rv shows that relocation entry 3 (offsets start at 0) in glue/nsCOMArray.o is... 000003be False long n/a SECTDIF True 0x000003f8 False long n/a PAIR True 0x00000344 and entry 7 is... 00000353 False long n/a SECTDIF True 0x000003f8 False long n/a PAIR True 0x00000344 Disassembling nsCOMArray.o with otool -tv, and looking for addresses 3be and 353, respectively, gives... 000003bc leal __ZN11nsISupports11COMTypeInfoIiE4kIIDE-0x344(%ebx),%ecx (which is in function __ZNK15nsCOMArray_base13IndexOfObjectEP11nsISupports, i.e. _ZNK15nsCOMArray_base13IndexOfObjectEP11nsISupports) and... 00000351 leal __ZN11nsISupports11COMTypeInfoIiE4kIIDE-0x344(%ebx),%ecx Note: __ZN11nsISupports11COMTypeInfoIiE4kIIDE demangles as nsISupports::COMTypeInfo<int>::kIID What seems to be happening here is that nsISupports::COMTypeInfo<int>::kIID is a constant inside a template, and so is in a coalesced constant section. However, it seems that the ld on OS X won't link static libraries (like the XPCOM glue) into shared libraries, if it means that the dynamic library has to reference a coalesced section.

Removing the NS_HIDDEN from kIID fixes this issue. This is because gcc4 on OSX will not coalesce template across dynamic libraries if visibility is hidden: From http://developer.apple.com/releasenotes/DeveloperTools/RN-GCC4/ "If you want to ensure that a template instantiation in a dylib is not merged with template instantiations in any other dylib, use the visibility attribute to give the template hidden visibility." It also doesn't make sense to hide something like kIID when we explicitly want everyone to share it.

We do not want everyone to share it and we do explicitly want frozen-linkage code to use your own copy. I'm not sure what a coalesced section means. On ELF systems, we want the reference to kIID to be made as a direct call, and not made through the PLT.

I think keeping it hidden is the right thing to do. My suspicion is that the .a needs to be built differently, but not sure how - even after nearly seven years at Apple, there's a bunch of this I still don't grok. We do want coalescing between .a's and within a dylib, so the release note is not entirely relevant.

I think this should be blocking 1.9 because C++ XPCOM components are very important to the extensibility and Mozilla-as-a-platform stories and as far as I can tell this will make them unusable on Mac OS X.

Firefox itself uses frozen linkage for components such as browsercomps, so this is not a general problem but somehow specific to your situation.

I think that I am using frozen linkage here (certainly it compiles without having to define anything like MOZILLA_INTERNAL_API). It looks like this results from using -lxpcomglue_s together with -bundle, which I believe is the normal way to make frozen linkage XPCOM components).

We compile our components with -lxpcomglue_s and -bundle and have never seen this problem. Here's a typical link line for us: gcc -o sbLibraryManager.dylib -lpthread -lobjc -shared-libgcc -lstdc++ -Wl,-executable_path,../../../../../compiled/dist/Songbird.app/Contents/Frameworks/XUL.framework -bundle -L../../../../../dependencies/macosx-i686/mozilla/debug/lib sbLibraryManager.o sbMediaListViewMap.o sbLibraryManagerModule.o -lplds4 -lnspr4 -lxpcom -lxpcomglue_s

This bug is dead, since it's obviously working in general.