This is a messy problem and I apologize in advance for the length of this message. I recently migrated a project from XCode 2.5 on Tiger to XCode 3.2 on Snow Leopard and ran into an unanticipated problem with the Intel C++ compiler 11.1 for OS X ("icc"). I want to build universal applications that are backward compatible to Tiger. * If I build with gcc using the 10.4 SDK, all goes well (but I want to use icc!). * If I build with icc using the 10.5 SDK, the build completes successfully and runs on Snow Leopard, but will not launch on Tiger (console output contains an error message about an undefined symbol, and I haven't pursued this further). * If I build with icc using the 10.4 SDK (which is what I really want to do), my compile dies with the message: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:0 catastrophic error: could not open source file "stdarg.h" (no directories in search list) The problem is that there is no "stdarg.h" file included in the icc distribution. The header contained in both the 10.4 and 10.5 SDKs looks like this: /* This file is public domain. */ /* GCC uses its own copy of this header */ #if defined(__GNUC__) #include_next #elif defined(__MWERKS__) #include "mw_stdarg.h" #else #error "This header only supports __MWERKS__." #endif So what's apparently happening is that __GNUC__ is defined and it tries to go to the next entry in the search path for the "real" stdarg.h, but there is no search path. I can't figure out why this happens with the 10.4 SDK but not the 10.5 SDK, but it seems to be related to use of icc because everything works fine with gcc. I can force a file trying to include "stdarg.h" to compile successfully by adding "/usr/lib/gcc/powerpc-apple-darwin10/4.2.1/include" to the header search path, but this obviously isn't the right thing to do, as it will always prefer a gcc header rather than an intel one when both are present. Is there some solution or workaround, or am I just SOL if I want to use XCode 3.2 for the builds? Thanks, Dave
For more complete information about compiler optimizations, see our Optimization Notice.