No Xcode 8 CLT for El Capitan

Thu Sep 22 14:28:42 PDT 2016

> On Sep 22, 2016, at 12:32, Adam Dershowitz <dersh at alum.mit.edu> wrote:
> 
> 
> 
>> On Sep 22, 2016, at 3:24 PM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:
>> 
>> 
>>> On Sep 22, 2016, at 10:37, Adam Dershowitz <dersh at alum.mit.edu> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 22, 2016, at 1:07 PM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:
>>>> 
>>>>> 
>>>>> On Sep 22, 2016, at 07:19, Adam Dershowitz <dersh at alum.mit.edu> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 22, 2016, at 4:49 AM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Sep 21, 2016, at 12:45, Adam Dershowitz <dersh at alum.mit.edu> wrote:
>>>>>>> 
>>>>>>> It does:
>>>>>>> 
>>>>>>> $ xcode-select -p
>>>>>>> /Applications/Xcode.app/Contents/Developer
>>>>>>> 
>>>>>>> 
>>>>>>> For me some updates in Macports, including some builds, seem to work OK, and others, such as cmake, are giving an error:
>>>>>>> https://trac.macports.org/ticket/52258
>>>>>>> 
>>>>>>> I’m not sure if I then need to completely switch to Xcode 7?  Or if I can just install the command line tools for 10.11 Xcode 7.3.1?  If I do that, where do they install, so that I can point xcode-select to the proper path?
>>>>>> 
>>>>>> If you don't have the CLTools installed, you wouldn't be able to install most of MacPorts.  I'm pretty sure you likely have them installed.
>>>>>> 
>>>>>> Dropping back down to Xcode 7 would mean that Xcode.app would contain the 10.11 SDK and would workaround your issue, but the issue is that the port isn't honoring your SDK (and maybe deployment target) selections (which default to / and host os version respectively).
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> Something is still not clear to me.  I had Xcode 7 installed.  I was under the impression that it included the SDK internally, so I don’t think that I had separately installed the CLTools (although I’m not positive).  
>>>> 
>>>> Do you have /usr/include on your system?  If you do, you installed the CLTools.
>>> 
>>> Yes, I do.  Although I can’t confirm when I might have installed it (is there an easy way to tell if the headers were from some older version i.e. 10.7,10.8 etc?).
>> 
>> $ pkgutil --file-info /usr/include/AvailabilityInternal.h
>> 
>> or just:
>> 
>> $ grep 'define __MAC_OS_X_VERSION_MAX_ALLOWED' /usr/include/AvailabilityInternal.h
>> 
>> The OS upgrade should remove that path, so you likely installed it at some point since upgrading your OS.
> 
> I do have the 10.11 tools installed (although they are slightly different from each other and from my current OS:
> 
> $ pkgutil --file-info /usr/include/AvailabilityInternal.h
> volume: /
> path: /usr/include/AvailabilityInternal.h
> 
> pkgid: com.apple.pkg.DevSDK
> pkg-version: 10.11.3.0.1.1456982112
> install-time: 1457024872
> uid: 0
> gid: 0
> mode: 644
> 
> pkgid: com.apple.pkg.DevSDK_OSX1011
> pkg-version: 7.3.1.0.1.1461711523
> install-time: 1462497081
> uid: 0
> gid: 0
> mode: 644
> $ grep 'define __MAC_OS_X_VERSION_MAX_ALLOWED' /usr/include/AvailabilityInternal.h
>        #define __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_11_4
> 
> But, likely close enough.  

Yep, there were no SDK changes in 10.11.5 and 10.11.6, so there was no need to release SDK updates for those OS versions.

What you have there is exactly as expected.

>>>>> And, I have used macports for many years without a problem (over many versions of Xcode).  When Xcode 8 was released I installed it, but didn’t install CLTools either.
>>>>> What still isn’t clear to me is if cmake and openmodelica (which does have the same problem as cmake, but it also depends on cmake so I tried to build that with the working cmake) should work with my current configuration?  Do they each have a bug?  Should just installing 10.11 CLTools allow them to build?
>>>> 
>>>> It's possibly a bug in cmake and openmodelica ports (they're using the SDK inside of Xcode.app even though MacPorts is configured to use /).
>>>> 
>>>> It's definitely a bug in cmake and openmodelica upstream.  They're failing to build properly for the older deployment targets when using newer SDKs.
>>> 
>>> In that case, it sounds likely that installing the newer CLTools won’t help, since I already have /usr/include.  So, at this point my options are to wait for bug fixes, or to downgrade.
>> 
>> Yes.
> 
> One other question.  As openmodelica uses cmake to build.  Is it likely that the bug in cmake is also affecting openmodelica (cache, links, stored paths etc)?  Or, instead is it more likely that each happens to have the identical problem, independent of each other?

They are a bit independent.  It's more of a development paradigm shift.  With modern SDKs (like macOS, iOS, and I believe also Android and Windows), the SDK advertises support for the newest functionality that the SDK supports (eg: new features in macOS 10.12) and annotates them with particular availability.  Apps expecting to run on older versions than when the support landed (eg: running on macOS 10.11) need to check for that support at runtime and have a fallback codepath.  Many OSS projects predate that model and assume that the SDK defines only what is in the minimum deployment target.  That's why using the 10.12 SDK on 10.11 or the 10.11 SDK on 10.10 can be problematic when dealing with such OSS projects.

> 
> Again, thank you.
> 
> 
>> 
>>>>> Perhaps the answer, that I was missing, is that to use Xcode 8, on 10.11, the user must explicitly install CLTools, but that would not be the case to run Xcode 7 on 10.11 or Xcode 8 on 10.12?
>>>> 
>>>> Depends on your perspective.  We'd like to be in the world where you don't need to install the system headers, but 90% of OSS software fails when the SDK is newer than the base system because most OSS assumes that the SDK matches the minimum deployment target.
>>> 
>>> 
>>> Thanks.  
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20160922/a7d5d0c1/attachment.p7s>