The default bug view has changed. See this FAQ.

NodeList DOM bindings break the build with clang

RESOLVED FIXED in mozilla10



6 years ago
6 years ago


(Reporter: Ehsan, Assigned: Ehsan)


Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments)



6 years ago
Created attachment 565953 [details]
build failure log

The libxul build now fails.  I'm attaching a log to the bug.
Hmm, weird, no idea what's wrong :-/.

Comment 2

6 years ago
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
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

I am building on 10.7, with clang 141650 and mozilla-central 9e090190e01e01c43770642de032f3b6b76c7e4c (the git clone)

Comment 4

6 years ago
Bisecting points to 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.

Comment 5

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

Comment 6

6 years ago
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.

Comment 7

6 years ago
Created attachment 566290 [details] [diff] [review]
Patch (v1)
Assignee: nobody → ehsan
Attachment #566290 - Flags: review?(peterv)

Comment 8

6 years ago
My patch basically instantiates the templates explicitly instead of relying on the compiler to do it for us.
Attachment #566290 - Flags: review?(peterv) → review+

Comment 9

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

Comment 11

6 years ago
Target Milestone: --- → mozilla10

Comment 12

6 years ago
Try run for f0546be1ca70 is complete.
Detailed breakdown of the results available here:
Results (out of 18 total builds):
    success: 17
    warnings: 1
Builds available at
Last Resolved: 6 years ago
Resolution: --- → FIXED
The reduced testcase is

void NewProxyObject(void *);
template<class T> struct NodeList  {
  static NodeList instance;
  virtual void getPropertyDescriptor();
  static void create();
void foobar() {
template<class T> NodeList<T>::NodeList() {
template<class T> void NodeList<T>::getPropertyDescriptor() {
template<class T> void NodeList<T>::create() {
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 which got fixed by r132331.
You need to log in before you can comment on or make changes to this bug.