The libxul build now fails. I'm attaching a log to the bug.

Hmm, weird, no idea what's wrong :-/.

I'll try bisecting the range to see if I can find the offending patch...

I could not reproduce this with this mozconfig: ---------------------------- ac_add_options --disable-optimize ac_add_options --enable-debug ac_add_options --enable-libxul ac_add_options --enable-application=browser ac_add_options --enable-tests ac_add_options --enable-trace-malloc ac_add_options --enable-accessibility # For NSS symbols export MOZ_DEBUG_SYMBOLS=1 ac_add_options --enable-debug-symbols="-gdwarf-2" # Enable parallel compiling mk_add_options MOZ_MAKE_FLAGS="-j4" # Needed to enable breakpad in application.ini export MOZILLA_OFFICIAL=1 --------------------------------- I am building on 10.7, with clang 141650 and mozilla-central 9e090190e01e01c43770642de032f3b6b76c7e4c (the git clone)

Bisecting points to http://hg.mozilla.org/mozilla-central/rev/71625e542826 as the first broken revision. The interesting thing which happened there is templatizing the NodeList class. It's possible that clang is not instantiating the templatized functions for some reason. Using nm to find __ZN3xpc3dom8NodeListI17nsIHTMLCollectionE21getPropertyDescriptorEP9JSContextP8JSObject4jsidbP20JSPropertyDescriptor for example only points to dom_quickstubs.o referencing it, but no .o file is defining it. I'm currently building with gcc to see which .o file defines it there.

That symbol is defined in dom_quickstubs.o for a gcc build...

So, it seems like explicitly instantiating NodeList<nsINodeList> and NodeList<nsIHTMLCollection> fixes the build by causing clang to instantiate everything correctly. I don't really know what's causing gcc to instantiate the template and clang not to, but I don't care too much to find out the cause. What I suspect is that we are only using NodeList's static members in this translation unit, so technically the compiler doesn't need to instantiate the class. Now, I have to figure out what needs to change on the trunk, because the NodeList class does not exist (at least in that form) any more.

My patch basically instantiates the templates explicitly instead of relying on the compiler to do it for us.

This has been fixed in recent clangs, I reducing the case to have a log if someone else hits this problem.

Try run for f0546be1ca70 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=f0546be1ca70 Results (out of 18 total builds): success: 17 warnings: 1 Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-f0546be1ca70

The reduced testcase is void NewProxyObject(void *); template<class T> struct NodeList { static NodeList instance; NodeList(); virtual void getPropertyDescriptor(); static void create(); }; void foobar() { NodeList<int>::create(); } template<class T> NodeList<T>::NodeList() { } template<class T> void NodeList<T>::getPropertyDescriptor() { } template<class T> void NodeList<T>::create() { NewProxyObject(&NodeList<T>::instance); } template<class T> NodeList<T> NodeList<T>::instance; Older versions of clang would not cause a template instantiation and get an undefined reference to getPropertyDescriptor from the vtable (which is used in the constructor, which is used to initialize the static variable). On the clang side this was http://llvm.org/bugs/show_bug.cgi?id=10020 which got fixed by r132331.