Upgrade cctools unexpectedly failing

[Joshua Root]

On 2019-10-9 02:48 , Ryan Schmidt wrote:
> If we used the "MacOSX.sdk" (instead of the versioned one) the fact that it gets baked into things wouldn't be a problem*. We should do this, but it will require restructuring how we do SDKs. Currently we impose a default SDK version based on the OS version, which ports can (and some do) override, so by the time MacPorts tries to see what SDK path should be used it no longer knows whether the SDK version was specifically requested or just set as a default. We should default to no SDK version. Then ports that need a specific SDK version can set it.
> 
> *Well, not as much of a problem. It may still be a problem in that it's relative to either the Xcode directory or the CLT directory. If we build a binary on the buildbot, which has Xcode, and an Xcode-relative SDK path gets baked in, and a user installs that binary on a system without Xcode, they could get errors when building other ports. Now that we added the "use_xcode" Portfile variable and use the CLT SDK path for ports that don't set that, even if Xcode is installed, this part of the problem should lessen over time as ports get updated and thus rebuilt, but to make it completely go away we would have to identify all of those binary archives of ports that don't set "use_xcode yes" that were already built that contain a baked-in Xcode SDK path and rebuild those binaries so that they have CLT SDK paths.

Using MacOSX.sdk is not a viable solution because build systems will see
symbols that aren't actually available in the OS. Almost nothing handles
weak-linking properly.

- Josh