Have you set the “User Header Search Paths” with /opt/local/… and the “Always search user paths” build settings? These set up the user header search paths which get searched before any system paths, and the “Always search user paths” essentially puts the user header search paths in front of the system paths for all header search, including when searching for included header files.
Jonathan > On Mar 18, 2016, at 2:14 PM, Carl Hoefs <newsli...@autonomy.caltech.edu> > wrote: > > Thanks for the very interesting info and idea. I might well be able to > jury-rig my project to get it to build my way on my Mac, but in the end the > Xcode project will have to be buildable on a generic Mac, so I'm bound by > whatever version of code Apple has included in their SDK. For the moment I've > been able to devise workarounds to make this doable, but just barely. If the > code under ../MacOSX10.11.sdk/usr/.. wasn't so outdated it wouldn't be a big > deal, but it seems this portion of the SDK lags behind at least 1 major > version. > -Carl > >> On Mar 17, 2016, at 11:05 PM, billn <b...@bno.id.au> wrote: >> >> 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/newslists%40autonomy.caltech.edu >> >> This email sent to newsli...@autonomy.caltech.edu > > > _______________________________________________ > 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/jprescott12%40icloud.com > > This email sent to jprescot...@icloud.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
