> On Sep 28, 2017, at 15:54, Ryan Schmidt <[email protected]> wrote:
>
>> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
>> in repository macports-base.
>>
>>
>> https://github.com/macports/macports-base/commit/69c745b2d71ac333d21da953497fd6ae903ce242
>>
>> commit 69c745b2d71ac333d21da953497fd6ae903ce242
>>
>> Author: Jeremy Huddleston Sequoia <[email protected]>
>> AuthorDate: Mon Sep 4 15:19:04 2017 -0700
>>
>>
>> portconfigure: Don't fall back on macosx if we are unable to find an
>> appropriate versioned SDK
>>
>> Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
>>
>> ---
>> src/port1.0/portconfigure.tcl | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/port1.0/portconfigure.tcl b/src/port1.0/portconfigure.tcl
>> index 4b9f02e..a93e05d 100644
>> --- a/src/port1.0/portconfigure.tcl
>> +++ b/src/port1.0/portconfigure.tcl
>> @@ -419,10 +419,14 @@ proc portconfigure::configure_get_sdkroot
>> {sdk_version} {
>> return $sdk
>> }
>>
>> - if {![catch {set sdk [exec xcrun --sdk macosx --show-sdk-path 2>
>> /dev/null]}]} {
>> - ui_warn "Unable to determine location of the macOS ${sdk_version}
>> SDK. Using the default macOS SDK."
>> - return $sdk
>> - }
>> + # TODO: Support falling back to "macosx" if it is present?
>> + # This leads to problems when it is newer than the base OS
>> because many OSS assume that
>> + # the SDK version matches the deployment target, so they
>> unconditionally try to use
>> + # symbols that are only available on newer OS versions..
>> + #if {![catch {set sdk [exec xcrun --sdk macosx --show-sdk-path 2>
>> /dev/null]}]} {
>> + # ui_warn "Unable to determine location of the macOS ${sdk_version}
>> SDK. Using the default macOS SDK."
>> + # return $sdk
>> + #}
>
> But this doesn't really help, does it? Xcode 8 only contains the 10.12 SDK,
> so when running on OS X 10.11 the only SDK you can use is a mismatched one.
> Similarly with Xcode 9 which only contains the 10.13 SDK even when running on
> macOS 10.12.
>
> So, what does the code now do in these situations where an SDK matching the
> OS version does not exist?
For systems that do not have the DevSDK (the part of the Command Line Tools
package that installs the headers into /usr/include, etc.) installed, we will
use a real SDK. If the version of the SDK inside of the selected Xcode.app is
newer (eg: 10.13 when running on 10.12), we will look for the matching SDK in
/Library/Developer/CommandLineTools/SDKs. If none is found, we err out. Other
systems (eg: homebrew) went down the path of trying to support newer SDKs, but
that's a big pile of mess that I don't want to get into.
For Joe User running on macOS 10.12 with Xcode 9, I suggest installing the
DevSDK (via the CLTools package from developer.apple.com). For Jane Developer
interested in testing this out, it just takes some manual setup:
1) Do not install the CLTools package (hopefully obvious, but worth noting
as it's not easy to remove it once installed)
2) Run from Terminal:
sudo mkdir -p /Library/Developer/CommandLineTools/SDKs/
sudo cp -a
/path/to/Xcode-8.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
/Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk
If you are running 10.12 with Xcode 8.x or 10.13 with Xcode 9.x, things should
"just work" without installing the CLTools package. I have been using MacPorts
without a DevSDK on all of my 10.12+ machines for almost a year now without
much issue. The only remaining gotchas that I'm aware of are in gcc (due to
upstream bugs that have URLs referenced in the Portfile) and the issue of
"newer" SDKs in newer Xcodes (which is why I just decided to not support that).
--Jeremy
