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

MacPorts noreply at macports.org
Mon Aug 5 14:35:56 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 Ionic):

 Neither change won't fix builds on 10.9 and below anyway. 10.9 for
 instance can at most use the qt58 ports, newer versions are not supported.
 Clearing `${configure.sdk_version}` is also only done when using Xcode 7+,
 which is only available on 10.10 and higher.

 Currently, building the port still fails, because:
   - `${configure.sdkroot}` is set to an empty string (because
 `${configure.sdk_version}` matches the running OS version and
 `/usr/include` exists)
   - access to the directory containing SDKs (Xcode) is denied
   - qmake can't resolve the "macosx" SDK location

 CLT on older platforms do not ship any SDK, so we're forced to either use
 the SDKs provided by Xcode or no SDK/sysroot at all.

 If I clear `${configure.sdk_version}`, this happens:
   - `${configure.sdkroot}` is still empty, because it tries to go down the
 `!use_xcode` route, executes `env DEVELOPER_DIR=${cltpath} xcrun --sdk
 macosx${sdk_version} --show-sdk-path 2> /dev/null` which essentially means
 calling `env DEVELOPER_DIR=/Library/Developer/CommandLineTools xcrun --sdk
 macosx --show-sdk-path 2> /dev/null`. This outputs an empty string and
 does NOT return an error code != 0, so base thinks the command succeeded
 and takes the empty string as the SDK path...
   - same as above

 Sadly, qmake-based ports always want to use an SDK. I've tried hacking
 around setting `CONFIG-=sdk`, but that only led to yet another build error
 due to Xcode being unusable. It also tried to use a compiler symlink in
 `${prefix}` opportunistically, so that's not a great idea anyway.

 I don't think we can phase out the Xcode dependency on systems with Xcode
 6 and below, since Xcode is the only package providing SDKs there.
 Disallowing the usage of SDKs (on older system) would solve that problem,
 but likely create a myriad of new ones (see qmake-based ports).
 Also, technically, trace mode will need to always allow access to the
 selected SDK root on older platforms. What doesn't help is that we'd
 essentially need a crystal ball to foresee whether a port will use an SDK
 or not - again, see qmake-based ones. `${configure.sdkroot}` will be empty
 (because base assumes that `/` will be used and no SDK is necessary), but
 the port actually wants to use an SDK. That might be a good example for
 the qmake5-1.0 PG having to set `use_xcode yes` on older platforms, but
 that would likewise just work around a base shortcoming.

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


More information about the macports-tickets mailing list