#41783: Always use Mac OS X SDK ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: wontfix | Keywords: Port: | ---------------------------+-------------------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => wontfix Comment: Time to put this ticket out of its misery. My year or two of using this patch on my own system has shown that the SDK path gets baked into various ports, which is undesirable. For example, it gets baked into various *-config programs, pkg-config *.pc files, and similar files in other software (like perl). This in turn causes other software to try to use that SDK—even if it no longer exists. One situation when this happens is if you install and `xcode-select` a beta version of Xcode (which is called Xcode-beta.app). The SDK paths that get baked into the programs include path to Xcode-beta.app. When you later remove Xcode-beta.app and install and select a final Xcode version, things fail when the SDK can't be found. This can be worked around by creating an Xcode-beta.app symlink pointing to Xcode.app. You'd have a similar problem if you ever renamed or moved Xcode. Another situation is when running Xcode 7 on OS X 10.10 Yosemite. Xcode 7 only includes the 10.11 SDK. If you have a library that was built with the 10.10 SDK when you were using Xcode 6, and it recorded the SDK flags into its config files, other programs that try to use that library will fail when the old SDK doesn't exist. Using the newest SDK is clearly what Apple wants us to do, so that should be the way that works best. The one case that was of interest to me where that does not work is if you are trying to compile software for PowerPC. The last SDK to support the ppc arch was the 10.6 SDK. And the last SDK to support the ppc64 arch was the 10.5 SDK. So if for example you are on 10.6 but want to build for ppc64, you have to use the 10.5 SDK. At this point, I'm not sure if anyone other than myself is still interested in that, so it should not be a consideration for MacPorts. -- Ticket URL: <https://trac.macports.org/ticket/41783#comment:14> MacPorts <https://www.macports.org/> Ports system for OS X