Always use Mac OS X SDK

[ryandesign (Ryan Carsten Schmidt)]

MacPorts 2.2 currently only uses a Mac OS X SDK if the macosx_deployment_target is different from the current Mac OS X version, or on PowerPC on 10.4 when building universal.

The only reason that I can see why we're not using an SDK in all cases is that on 10.4 using an SDK introduces problems linking with non-SDK libraries (such as MacPorts-provided libraries); see e.g. #25053. But changing Tiger's default compiler from gcc-4.0 to apple-gcc-4.2 may fix that problem; see #41782.

Using an SDK in all cases (or at least on Mavericks and later) seems to fix a kde build failure on Mavericks with MacPorts trunk; see #41321.

I've made a patch for this and will test it out for awhile on my various systems to see if this introduces any new problems.

[cooljeanius (Eric Gallager)]

Cc Me!

[gallafent]

Cc Me!

[gallafent]

I believe that #41589 may be related. It looks like a different value for deployment target between configure and build phases. Is it related, or am I mistaken?

[ryandesign (Ryan Carsten Schmidt)]

Replying to william@…:

I believe that #41589 may be related. It looks like a different value for deployment target between configure and build phases. Is it related, or am I mistaken?

Not related.

[ryandesign (Ryan Carsten Schmidt)]

I've attached the patch I'm testing for this, but it needs to be updated for changes made in r115429, and it can be simplified if #41782 is resolved first.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

Updated and simplified patch attached.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

The problem I'm encountering using this patch is when ports build using FSF GCC. Then I get e.g.:

gcc-mp-4.8: error: unrecognized command line option '-syslibroot'

[larryv (Lawrence Velázquez)]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

Jeremy's opinion is that specifying SDK shouldn't ever be needed at all. Which is exactly the contrary to what this patch is trying to do.

Always specifying SDK will most certainly break libc++ on 10.6 (but then again libc++ could install files inside the SDK). As a consequence at the moment it would break everything on 10.6 if libc++ is chosen by default in MacPorts configuration.

My experience tells me that specifying SDK explicitly is often needed, in particular when compiling for an older Mac OS X version (I'm not excluding software bugs for the problems). See #44125 and please talk to Jeremy.

[ryandesign (Ryan Carsten Schmidt)]

My understanding is that specifying the SDK is necessary when compiling for other (usually older) OS X versions (in addition to setting the deployment target to that OS X version), which is not a primary purpose of MacPorts but is nevertheless something some users want to do, and MacPorts has that capability, via unadvertised settings in macports.conf.

My motivation for wanting to always use the SDK is that editing these unadvertised settings often leads to build failures because nobody tests their ports with these settings changed. Always using the SDK would expose those problems to everyone, thus leading to the problems being noticed and hopefully fixed and improving the experience for users who want to change these settings.

However, in addition to the problems Mojca mentioned in comment:10 and the gcc problem I had in comment:7, using an SDK would require Xcode, and many users desire to be able to use MacPorts without Xcode, instead just using the command line tools. And I acknowledge that that would be nice, since the command line tools are tiny compared to Xcode, and users don't like to waste disk space, especially on an SSD. If we want to try to use SDKs more, then one possibility would be to only use the SDK if Xcode is installed, and not use it if only the command line tools are installed.

[ned-deily (Ned Deily)]

This may be a red herring but I believe it is the case that if -isysroot is supported by the compiler chain, like Apple's compilers do, you can always use just / as the SDK path if the system headers have been installed by the Command Line Tools. So you might be able to have it both ways: use a real SDK path (like from xcodebuild -version -sdk macosx Path), when it is available or desired, otherwise just use /.

[devernay (Frédéric Devernay)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

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.