• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Cross development header problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Cross development header problems


  • Subject: RE: Cross development header problems
  • From: "David Litwin" <email@hidden>
  • Date: Thu, 23 Feb 2006 18:32:31 -0800
  • Thread-topic: Cross development header problems

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

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Cross development header problems
  • Next by Date: Problem Static Linking in XCode
  • Previous by thread: Re: Cross development header problems
  • Next by thread: Problem Static Linking in XCode
  • Index(es):
    • Date
    • Thread