Re: Xcode 7 can't build "Command Line Tool" projects (Carl Hoefs)
Re: Xcode 7 can't build "Command Line Tool" projects (Carl Hoefs)
- Subject: Re: Xcode 7 can't build "Command Line Tool" projects (Carl Hoefs)
- From: Carl Hoefs <email@hidden>
- Date: Fri, 18 Mar 2016 11:14:18 -0700
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 <email@hidden> 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 <email@hidden>
>> To: Jens Alfke <email@hidden>
>> Cc: email@hidden
>> Subject: Re: Xcode 7 can't build "Command Line Tool" projects
>> Message-ID:
>> <email@hidden>
>> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
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