Title: no "proper" header files on macOS 10.14 Mojave
Type: compile error Stage: patch review
Components: macOS Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: ned.deily Nosy List: dimpase, erik.bray, ned.deily, ronaldoussoren
Priority: normal Keywords: patch

Created on 2019-03-08 10:03 by dimpase, last changed 2019-04-14 10:15 by dimpase.

File name Uploaded Description Edit
noincludedirs_OSX.patch dimpase, 2019-03-08 10:03 POC patch for "no-headers" OSX
Pull Requests
URL Status Linked Edit
PR 12825 open dimpase, 2019-04-14 10:07
Messages (6)
msg337461 - (view) Author: Dmitrii Pasechnik (dimpase) * Date: 2019-03-08 10:03
Neither Xcode nor its command-line tools on macOS 10.14 Mojave come with header files installed in /usr/ and other "normal" directories.

This is not documented in

While an extra step to handle this, i.e. to install the headers, is available (see a discussion on, Apple stated that this workaround will disappear.

It is thus highly desirable to provide a way to deal with headers located not at /usr/include, but at `xcrun --show-sdk-path`/usr/include.
A small change in along the lines of the following:

--- a/
+++ b/
@@ -134,7 +134,8 @@ def macosx_sdk_root():
     cflags = sysconfig.get_config_var('CFLAGS')
     m ='-isysroot\s+(\S+)', cflags)
     if m is None:
-        sysroot = '/'
+        import subprocess
+        sysroot = subprocess.check_output(["xcrun", "--show-sdk-path"]).decode("utf-8").strip('\n')
         sysroot =
     return sysroot
@@ -146,6 +147,7 @@ def is_macosx_sdk_path(path):
     return ( (path.startswith('/usr/') and not path.startswith('/usr/local'))
                 or path.startswith('/System/')
+                or path.startswith('/Applications/')
                 or path.startswith('/Library/') )

with the necessary changes to enable various modules (see attachment for a complete POC diff against the current master), the result builds and passes all the (enabled) tests on an OSX 10.13 system with empty /usr/include and /usr/local/include containing only LZMA headers.

Needless to say, a proper patch would not modify Modules/Setup, it'd adjust etc.
msg337540 - (view) Author: Dmitrii Pasechnik (dimpase) * Date: 2019-03-08 22:10
Needless to say, subprocess is most certainly an overkill, something less involved would do the job, without the need for all the module dependencies of subprocess.
msg337680 - (view) Author: Erik Bray (erik.bray) * (Python triager) Date: 2019-03-11 15:49
Perhaps it would be better if the `xcrun --show-sdk-path` thing were run at configure-time and its result shoved into a variable we can read with sysconfig.get_config_var()
msg337906 - (view) Author: Dmitrii Pasechnik (dimpase) * Date: 2019-03-14 09:14
I won't mind to provide a PR for this. but it is not clear what the goal should be. Is it to build a working OSX Python with as few external to Xcode deps (it seems that only lzma is needed) as possible?
msg337912 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-03-14 13:12
Thanks for the report and for the PR offer but let's hold off on that for the moment: I'm planning to merge a somewhat different approach.
msg340202 - (view) Author: Dmitrii Pasechnik (dimpase) * Date: 2019-04-14 10:15
In case,I have opened PR
to provide our solution to this issue.
Date User Action Args
2019-04-14 10:15:16dimpasesetmessages: + msg340202
2019-04-14 10:07:17dimpasesetstage: patch review
pull_requests: + pull_request12750
2019-03-14 13:12:07ned.deilysetassignee: ned.deily
messages: + msg337912
2019-03-14 09:14:06dimpasesetmessages: + msg337906
2019-03-11 15:49:28erik.braysetnosy: + erik.bray
messages: + msg337680
2019-03-08 22:10:03dimpasesetmessages: + msg337540
2019-03-08 10:03:47dimpasecreate