If you build Firefox Trunk with Apples Clang (Xcode 4), you get the following fatal error: In file included from nssb64d.c:44: In file included from /Developer/mozilla/obj-x86_64-apple-darwin10.7.0/dist/include/nspr/nspr.h:62: In file included from /Developer/mozilla/obj-x86_64-apple-darwin10.7.0/dist/include/nspr/prprf.h:60: /Developer/SDKs/MacOSX10.6.sdk/usr/include/stdarg.h:4:15: fatal error: 'stdarg.h' file not found #include_next <stdarg.h> ^ 1 error generated. make[7]: *** [/Developer/mozilla/obj-x86_64-apple-darwin10.7.0/nss/nssutil/nssb64d.o] Error 1 make[6]: *** [libs] Error 2 make[5]: *** [libs] Error 2 make[4]: *** [libs_tier_platform] Error 2 make[3]: *** [tier_platform] Error 2 make[2]: *** [default] Error 2 make[1]: *** [realbuild] Error 2 make: *** [build] Error 2 It builds with Clang trunk.

It also builds fine with the 2.9 branch.

stdarg.h is a Standard C Library header. It is documented on page 254 of The C Programming Language, Second Edition. But I don't see stdarg.h in the /usr/include directory on Ubuntu 10.04. Strange.

It is provided by the compiler. For example, in my machine I have: /usr/lib/gcc/x86_64-redhat-linux/4.5.1/include/stdarg.h /home/espindola/inst/clang/lib/clang/3.0/include/stdarg.h I remember seeing this when first trying to build with clang. I am almost sure the problem was https://bugzilla.mozilla.org/show_bug.cgi?id=629839 The fix for that bug was to use -dumpversion, but I just noticed that version of clang in xcode 4 doesn't include revision 123296 which is the one that changed clang to produce a fake gcc version. To fix this bug (assuming the above assumption is really the problem), we can change security/coreconf/Darwin.mk to detect and handle the clang in xcode 4.

Interestingly, if I download the current m-c source, I don't have this dumpversion line: http://hg.mozilla.org/mozilla-central/file/1edfae12015b/security/coreconf/Darwin.mk#l63 But "GCC_VERSION_FULL := 4.2.1" will fix the error for me.

Rafael: did you mean to ask for review on attachment 524325 [details] [diff] [review]?

no, it was just a test. To do it right we have to figure a way to detect xcode 4 and handle it as gcc 4.2.1.

This is fixed with Apples latest Clang from Xcode 4.1. $ clang -v Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.0 Thread model: posix

Because I'm able to build TB/FF with Apples clang from Xcode 4.2 (4D199) without any problems, I will close this bug now. $ clang -v Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.2.0 Thread model: posix