[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