Two follow ups:
1.) It seems PER_ARCH_CFLAGS_ppc is the proper flag, not OTHER_CFLAGS_ppc.
Don’t be fooled by the list archive message from Chris that seems so
authoritative: (http://lists.apple.com/archives/xcode-users/2005/Jun/msg00384.html).
I suppose the Universal Binary Programming Guidelines is the comprehensive list
he mentions, and where I should have been looking before searching the archives
J
2.) Using PER_ARCH_CFLAGS_ppc puts my flags first, which means the system
frameworks will be found before the build directory –F include that is
automatically added for you. This seems wrong, but as I have no
frameworks doesn’t really bother my build. It could affect others
though.
David Litwin
BigFix
From:
xcode-users-bounces+david_litwin=email@hidden
[mailto:xcode-users-bounces+david_litwin=email@hidden] On Behalf Of David Litwin
Sent: Thursday, February 23, 2006
6:06 PM
To: Xcode Users
Subject: Cross development header
problems
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