Changes between Initial Version and Version 1 of Ticket #58779, comment 5


Ignore:
Timestamp:
Aug 1, 2019, 2:27:03 AM (5 years ago)
Author:
satraul (Satryaji Aulia)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #58779, comment 5

    initial v1  
    33>
    44> That doesn't seem to hold for 10.9 for instance. It's entirely possible that such setups only exist in older systems nowadays, but I have both CLT and Xcode installed and the paths all exist.
    5 Yes, the existence of /usr/lib/libxcselect.dylib (xcode-select) indicates macOS >= 10.9 which we assume is the earliest macOS version that moved CLT from / to /Library/Developer/CommandLineTools/. For < 10.9 we agreed that using CLT alone isn't sufficient enough so we always set use_xcode yes.
    6 >
    7 > > That would match what is done elsewhere. Using the headers in /usr/include is safer than using the SDK in Xcode because the latter could be for a newer OS version, which causes problems with build-time detection of features.
    8 >
    9 > Yeees, since Apple doesn't necessarily ship the needed SDK versions with all supported Xcode versions any longer. But also back then, using the provided SDKs was safer pre-SIP.
    10 >
    11 >
     5Yes, the existence of /usr/lib/libxcselect.dylib (xcode-select) indicates macOS >= 10.9 which we assume is the earliest macOS version that moved CLT from / to /Library/Developer/CommandLineTools/.
     6
     7For < 10.9 we agreed that using CLT alone isn't sufficient enough so we always set use_xcode yes.
    128> Not allowing access to the Developer dir isn't just problematic because of the SDKs, though. In #58770 I reported a build failure that I "fixed" by setting `use_xcode` to `true` in the port, but that workaround is wrong and stupid. Nothing within scons or gpsd actually uses xcrun - the call is a side-effect of the shims in /usr/bin (for clang for instance). In theory, we'd have to allow access to the Developer dir every time we use the system compiler as well.
    139