When building TB on MacOSX 10.8 opt get the following: Executing: /usr/local/bin/ccache ../../../../../clang/bin/clang++ -arch i386 -Qunused-arguments -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Werror=int-to-pointer-cast -Werror=type-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -isysroot /Developer/SDKs/MacOSX10.7.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNO_X11 -pipe -DNDEBUG -DTRIMMED -g -O3 -fno-omit-frame-pointer -fPIC -o XUL -Wl,-filelist,/builds/slave/tb-c-cen-osx64-000000000000000/build/objdir-tb/i386/mozilla/toolkit/library/tmp2Dr0ES.list -framework Cocoa -lobjc -framework AudioToolbox -framework ExceptionHandling -Wl,-executable_path,/builds/slave/tb-c-cen-osx64-000000000000000/build/objdir-tb/i386/mozilla/dist/bin -Wl,-dead_strip ../../js/src/libjs_static.a ../../js/src/libjs_static.a ../../xpcom/typelib/xpt/libxpt.a ../../intl/unicharutil/util/internal/libintl_unicharutil_util_internal.a ../../security/nss/lib/crmf/libcrmf.a ../../js/src/libjs_static.a ../../intl/icu/target/lib/libicui18n.a ../../intl/icu/target/lib/libicuuc.a ../../intl/icu/target/lib/libicudata.a ../../config/external/nss/libnss3.dylib ../../ldap/sdks/c-sdk/ldap/libraries/libldap/libldap60.dylib ../../ldap/sdks/c-sdk/ldap/libraries/libldif/libldif60.dylib ../../ldap/sdks/c-sdk/ldap/libraries/libprldap/libprldap60.dylib ../../memory/mozalloc/libmozalloc.dylib -dynamiclib -install_name @executable_path/XUL -compatibility_version 1 -current_version 1 -single_module -L/builds/slave/tb-c-cen-osx64-000000000000000/build/objdir-tb/i386/mozilla/dist/lib -lmozglue -lm -Wl,-framework,CoreLocation -Wl,-framework,QuartzCore -Wl,-framework,Carbon -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit -Wl,-framework,AddressBook -Wl,-framework,OpenGL -framework Cocoa -framework AudioToolbox -framework OpenGL -framework SystemConfiguration -framework QTKit -framework IOKit -F/System/Library/PrivateFrameworks -framework CoreUI -lcups /builds/slave/tb-c-cen-osx64-000000000000000/build/objdir-tb/i386/mozilla/toolkit/library/tmp2Dr0ES.list: StaticXULComponentsStart.o . . . ld: bad codegen, pointer diff in __ZN21XPCWrappedNativeScopeC2EP9JSContextN2JS6HandleIP8JSObjectEE to global weak symbol __ZTVN2JS10WeakMapPtrIP8JSObjectS2_EE for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[7]: *** [XUL] Error 1 make[6]: *** [toolkit/library/target] Error 2 Works fine for MacOSX 10.8 debug

Seems to be similar to bug 951743, maybe sfink can say.

Can you try -class JS_PUBLIC_API(WeakMapPtr) +class JS_FRIEND_API(WeakMapPtr) in js/public/WeakMapPtr.h, and maybe also do the same change to the two template instantiations in js/src/vm/WeakMapPtr.cpp?

(In reply to Steve Fink [:sfink] from comment #2) > Can you try > > -class JS_PUBLIC_API(WeakMapPtr) > +class JS_FRIEND_API(WeakMapPtr) > > in js/public/WeakMapPtr.h, and maybe also do the same change to the two > template instantiations in js/src/vm/WeakMapPtr.cpp? Unfortunately that not fix it. From the error it looks like it is somewhere in the XPCWrappedNativeScope, maybe around http://mxr.mozilla.org/comm-central/source/mozilla/js/xpconnect/src/XPCWrappedNativeScope.cpp#78 but probably wrong.

XPCWrappedNativeScope::XPCWrappedNativeScope(JSContext*, JS::Handle<JSObject*>) and vtable for JS::WeakMapPtr<JSObject*, JSObject*> are the two referenced items

(In reply to Ian Neal from comment #3) > (In reply to Steve Fink [:sfink] from comment #2) > > Can you try > > > > -class JS_PUBLIC_API(WeakMapPtr) > > +class JS_FRIEND_API(WeakMapPtr) > > > > in js/public/WeakMapPtr.h, and maybe also do the same change to the two > > template instantiations in js/src/vm/WeakMapPtr.cpp? > > Unfortunately that not fix it. From the error it looks like it is somewhere > in the XPCWrappedNativeScope, maybe around > http://mxr.mozilla.org/comm-central/source/mozilla/js/xpconnect/src/ > XPCWrappedNativeScope.cpp#78 but probably wrong. Just to confirm: that did not fix the WeakMapPtr vtable problem either? I wouldn't expect the proposed change to do anything for XPCWrappedNativeScope. If that doesn't fix it, it's going to be hard for me to make progress here. I don't have easy access to an osx box. I think glandium may need to take a look.

IIRC, jcranmer had the same problem and was investigating it.

The patch glandium suggested in bug 1039964 produced a working build on try. I can't explain why though.

(In reply to Joshua Cranmer [:jcranmer] from comment #7) > The patch glandium suggested in bug 1039964 produced a working build on try. > I can't explain why though. Would that patch but using JS_FRIEND_API instead of JS_PUBLIC_API be an option? https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=870a16b9dacd

(In reply to Ian Neal from comment #8) > (In reply to Joshua Cranmer [:jcranmer] from comment #7) > > The patch glandium suggested in bug 1039964 produced a working build on try. > > I can't explain why though. > > Would that patch but using JS_FRIEND_API instead of JS_PUBLIC_API be an > option? > > https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=870a16b9dacd Well it works on OSX but breaks locally on linux64 :(

I took a look at this especially as bug 1039964 implies we're doing something different to Firefox, and indeed we are. Bug 920731 stopped exporting the JS symbols from libxul (add MOZ_DISABLE_EXPORT_JS=1 in confvars.sh). I did a run on tryserver with the symbols export disabled, and calendar failed to link: https://tbpl.mozilla.org/php/getParsedLog.php?id=46636415&tree=Thunderbird-Try So I tested without calendar enabled, and that meant the MacOSX opt build completed successfully. The failures are: ndefined symbols for architecture i386: "JSAutoCompartment::JSAutoCompartment(JSContext*, JSObject*)", referenced from: calDateTime::SetJsDate(JSContext*, JS::Handle<JS::Value>) in calDateTime.o "JS_ObjectIsDate(JSContext*, JS::Handle<JSObject*>)", referenced from: calDateTime::SetJsDate(JSContext*, JS::Handle<JS::Value>) in calDateTime.o "JS_NewDateObject(JSContext*, int, int, int, int, int, int)", referenced from: calDateTime::GetJsDate(JSContext*, JS::MutableHandle<JS::Value>) in calDateTime.o "JSAutoCompartment::~JSAutoCompartment()", referenced from: calDateTime::SetJsDate(JSContext*, JS::Handle<JS::Value>) in calDateTime.o "JS_NewDateObjectMsec(JSContext*, double)", referenced from: calDateTime::GetJsDate(JSContext*, JS::MutableHandle<JS::Value>) in calDateTime.o ld: symbol(s) not found for architecture i386 Fallen: Is there any way in Lightning we could work around not having these symbols exported? This would further sync us with Firefox and mean that we can work-around bug 1039964 easily.

There was a thread on this I commented on, see https://groups.google.com/forum/#!topic/mozilla.dev.platform/yC8Bg91ic5k it looks like there is a workaround, but it requires a lot of code changes and might affect Lightning's performance. If I need to do this now its really the worst time because I have exams coming up and have a lot to do. I might have some time to look into this mid September or in November.

Pushed to try https://tbpl.mozilla.org/?rev=e11793533d64&tree=Thunderbird-Try OS X 10.8 Opt build fails - https://tbpl.mozilla.org/php/getParsedLog.php?id=47647409&tree=Thunderbird-Try but it looks like a different issue.

Resolved this by porting bug 920731 as mentioned above (it needed other bugs to fully green as well): https://hg.mozilla.org/releases/comm-aurora/rev/8a44ad6139fe