[MacPorts] #58779: base: ports cannot use SDK inside of Developer dir unless using Xcode build type

MacPorts noreply at macports.org
Thu Aug 1 02:25:08 UTC 2019


#58779: base: ports cannot use SDK inside of Developer dir unless using Xcode build
type
---------------------+-----------------------
  Reporter:  Ionic   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  base    |    Version:  2.5.99
Resolution:          |   Keywords:  tracemode
      Port:          |
---------------------+-----------------------

Comment (by satraul):

 Replying to [comment:4 Ionic]:
 > > If you install both Xcode and the CLT then you won't have
 /Library/Developer/CommandLineTools/usr/bin/make, or at least I don't. If
 there is a case where that exists but the SDK inside Xcode is still used,
 that would be a problem.
 >
 > 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.
 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.
 >
 > > 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.
 >
 > 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.
 >
 >
 > 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.

 Thank you for the discovery, this is actually part of my project right now
 for MacPorts. Around 2 days ago, we discovered the qmake problem on Qt5,
 and planned a solution similar to #58770. And yes, the solution is a bad
 workaround.

 As you said, qmake does find the SDK on it's own by using `xcrun` here:
 [https://code.qt.io/cgit/qt/qtbase.git/tree/configure#n235] with `$sdk`
 resolving to `configure.sdk_version`.

 I just found out that there are many ports (~150) that depend on qmake, so
 I think we should consider a larger solution. Ccing my project mentors.

 The #58770 problem needs to be discussed seperately too. There may be more
 ports that call shims without MacPorts' environment variables. First with
 ports using `system -W`, now with scons (~26 ports).

-- 
Ticket URL: <https://trac.macports.org/ticket/58779#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list