Issue #25136: Support Apple Xcode 7's new textual SDK stub libraries.
As of Xcode 7, SDKs for Apple platforms now include textual-format stub
libraries whose file names have a .tbd extension rather than the
standard OS X .dylib extension. The Apple compiler tool chain handles
these stub libraries transparently and the installed system shared libraries
are still .dylibs. However, the new stub libraries cause problems for
third-party programs that support building with Apple SDKs and make
build-time decisions based on the presence or paths of system-supplied
shared libraries in the SDK. In particular, building Python itself with
an SDK fails to find system-supplied libraries during setup.py's build of
standard library extension modules. The solution is to have
find_library_file() in Distutils search for .tbd files, along with
the existing types (.a, .so, and .dylib). Patch by Tim Smith.
diff --git a/setup.py b/setup.py
index da67731..3ebc3de 100644
--- a/setup.py
+++ b/setup.py
@@ -136,6 +136,22 @@
p = p.rstrip(os.sep)
if host_platform == 'darwin' and is_macosx_sdk_path(p):
+ # Note that, as of Xcode 7, Apple SDKs may contain textual stub
+ # libraries with .tbd extensions rather than the normal .dylib
+ # shared libraries installed in /. The Apple compiler tool
+ # chain handles this transparently but it can cause problems
+ # for programs that are being built with an SDK and searching
+ # for specific libraries. Distutils find_library_file() now
+ # knows to also search for and return .tbd files. But callers
+ # of find_library_file need to keep in mind that the base filename
+ # of the returned SDK library file might have a different extension
+ # from that of the library file installed on the running system,
+ # for example:
+ # /Applications/Xcode.app/Contents/Developer/Platforms/
+ # MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/
+ # usr/lib/libedit.tbd
+ # vs
+ # /usr/lib/libedit.dylib
if os.path.join(sysroot, p[1:]) == dirname:
return [ ]