Xcode is designed to build projects for multiple OS architectures on multiple processor types. So it does not use the host system headers and libraries, because for many purposes like building TVOS apps they are inappropriate. Welcome to the rabbit hole world of cross compilation.
This magic is performed by putting all the the headers and libraries for the target system into an SDK directory. The compiler and linker are then given options like —sysroot which alter ALL header and library paths to be relative to the SDK directory. The default SDK for a MacOS target is "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk” If you look in that directory you will see a ‘System’ directory with all the default frameworks and a ‘usr’ directory containing headers and libraries. If you want to include you /opt stuff in the build, you could duplicate the existing default SDK with a different name and copy (not install because link paths are incorporated into .dyld libraries) the open source libraries in there. You probably need to mess with the .plist file. I renamed a copy SDK as 'MyOSX10.11.sdk’ and bodgied up the plist as below (only the name is changed in two places): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> <plist version="1.0"> <dict> <key>CanonicalName</key> <string>myosx10.11</string> <key>CustomProperties</key> <dict> <key>KERNEL_EXTENSION_HEADER_SEARCH_PATHS</key> <string>$(KERNEL_FRAMEWORK)/PrivateHeaders $(KERNEL_FRAMEWORK_HEADERS)</string> </dict> <key>DefaultProperties</key> <dict> <key>MACOSX_DEPLOYMENT_TARGET</key> <string>10.11</string> <key>PLATFORM_NAME</key> <string>macosx</string> <key>DEFAULT_KEXT_INSTALL_PATH</key> <string>$(LIBRARY_KEXT_INSTALL_PATH)</string> </dict> <key>DisplayName</key> <string>My OS X 10.11</string> <key>MaximumDeploymentTarget</key> <string>10.11</string> <key>MinimalDisplayName</key> <string>10.11</string> <key>MinimumSupportedToolsVersion</key> <string>3.2</string> <key>SupportedBuildToolComponents</key> <array> <string>com.apple.compilers.gcc.headers.4_2</string> </array> <key>Version</key> <string>10.11</string> <key>isBaseSDK</key> <string>YES</string> </dict> </plist> After restarting Xcode my bodged up SDK appeared in the SDKROOT selection popup of the build settings. Cautions: I have not built anything with this sort of setup in Xcode 7 but I have done with Xcode 6 which is similar, but puts the SDKs in a different location. Don’t expect Apple to accept anything built like this for the Mac App Store. Your milage may vary. Obviously your users need any linked libraries to be installed. The code will not run on the build machine unless the libraries are installed. Have fun Bill Northcott PS You can download older SDKs from the Apple developer site. You might even be able to make a Linux SDK and build for that. (No I have not done that) > > Message: 2 > Date: Wed, 16 Mar 2016 12:38:54 -0700 > From: Carl Hoefs <newsli...@autonomy.caltech.edu> > To: Jens Alfke <j...@mooseyard.com> > Cc: xcode-users@lists.apple.com > Subject: Re: Xcode 7 can't build "Command Line Tool" projects > Message-ID: > <4cd79593-6413-436c-b55c-e1e690cfd...@autonomy.caltech.edu> > Content-Type: text/plain; charset="utf-8" > > New assessment of this problem... > > Xcode 7.2.1 is getting mixed up between the header files in /usr/include and > those in /opt/local/include, and I can no longer build. > > My commandline OS X project uses the most recent version of OpenCV installed > in /opt/local. The problem is that OpenCV requires a newer version of ncurses > than is in the OS X 10.11 SDK. So, system-wide there are two versions of > ncurses: V5.7 installed in /usr/include, and V6.0 installed in > /opt/local/include. > > My Xcode header search paths setting: > > HEADER_SEARCH_PATHS = $(inherited) /opt/local/include/opencv > /opt/local/include/opencv2 /opt/local/include > > It seems /usr/include is hardcoded somewhere in Xcode, because Xcode begins > its parsing by loading up the *old* version of ncurses first: > > In file included from > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/ncurses.h:141: > > But when that ncurses.h does an #include <curses.h>, it seems to be loading > up the *new* version, /opt/local/include/curses.h, which is incompatible, and > generates a multitude of errors. > > How can I get Xcode to use the newer version installed in /opt/local/include, > and not the older one in /usr/include? > -Carl > _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
