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
