When one compiles for an older SDK the standard system
headers (at the level of the OS you are running) are still available and used, should
a file not be found in the SDK.
In my case I include dlfcn.h for dlopen(), and only now that
I’m linking found out that it isn’t available on 10.2.8. This
is because I am running 10.4.4 and when it couldn’t find the file in /Developer/SDKs/MacOSX10.2.8.sdk
it went and found it in /usr/include.
Is there a reason that, when compiling against a specific
SDK, the –nostdinc flag is not automatically passed to avoid this?
I suppose one reason is it is not clear what level of system headers you want
to ignore. Perhaps we need a –nosdkstdinc as well to clear this up.
It seems dangerous to leave it as is, where a developer is left thinking they
are getting a snapshot of just what was available on a certain system, but in
reality they are getting a mix of that SDK and their current system.
While a small bother, I can certainly add –nostdinc myself
to the OTHER_CFLAGS_ppc, but the unfortunate result of this is to also kill the
SDK framework path (/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks),
so I suddenly can’t find <Carbon/Carbon.h>.
Unlike the normal header paths (passed in with –I, so
they aren’t stripped out by –nostdinc), the SDK header path is not
specified with a –F, and just magically makes its way into the search
path. In fact, it seems to replace the system framework path. Perhaps this
is why it gets hammered by –nostdinc.
Is there some logic I’m missing or is this just a
bug? It seems my work around will require me to add:
OTHER_CFLAGS_ppc=-nostdinc –F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks
to my .xcconfig files.
It would be nice if this could be clarified. I’ll post a bug if
that’s the right route.
David Litwin
BigFix