Right, after learning way more than I ever wanted to know about xcrun,
I think I see the issue. When running with empty SDKROOT variable,
xcrun sets SDKROOT to "/" when running clang:
$ SDKROOT= xcrun --no-cache --log --verbose clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v
xcrun: note: PATH = '/usr/bin:/bin'
xcrun: note: SDKROOT = '/'
^ WRONG. there are no
python headers there
.
env SDKROOT=/
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v
...
#include "..." search starts here:
#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
clang gets the include path wrong
End of search list.
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c:15:10:
fatal error: 'Python/Python.h' file not found
#include
^
1 error generated.
^ and errors out
On the other hand, if I invoke xcrun with SDKROOT=macosx, everything
works just fine:
$ SDKROOT=macosx xcrun --no-cache --log --verbose clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v
xcrun: note: looking up SDK with
'/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk
macosx -version Path'
xcrun: note: PATH = '/usr/bin:/bin'
xcrun: note: SDKROOT = 'macosx'
xcrun: note: TOOLCHAINS = ''
xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer'
xcrun: note: XCODE_DEVELOPER_USR_PATH = ''
xcrun: note: xcrun_db =
'/var/folders/bt/tws6gynx0ws1cc4ss53_pvqmgq/T/xcrun_db'
xcrun: note: lookup resolved to:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk'
xcrun: note: PATH = '/usr/bin:/bin'
xcrun: note: SDKROOT =
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk'
^^ correct. a valid SDK is located there
...
env
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v
...
#include "..." search starts here:
#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks
(framework directory)
^ include path is good and compilation succeeds
I've checked this on 10.12 and the xcrun behavior is same there (with
the difference that 10.12 does contain headers in
/System/Library/Frameworks.
It seems we could fix this by changing the invocation in dotest to
explicitly request SDKROOT=macosx. As far, as I can tell, this would
only break if someone tried to run dotest with iOS as host, but I
don't think that's ever going to be supported(?)
What do you think?
On 15 November 2017 at 20:25, Jim Ingham wrote:
> The build should be finding the version in the SDK within Xcode. I do have
> the CommandLineTools directory on my system, but it doesn’t have an SDK
> directory in it. I wonder if that is causing the problem?
>
> One thing to check, do:
>
> $ xcrun -find clang
>
> Does that find clang in the DeveloperTools directory? If so try:
>
> sudo xcode-select —switch /Applications/Xcode.app
>
> Then everything should point to the toolchain & SDK’s in Xcode. If that
> doesn’t help you might try moving the DeveloperTools aside and see if things
> work then. Xcode should not need that to work.
>
> Jim
>
>
>> On Nov 15, 2017, at 10:33 AM, Pavel Labath wrote:
>>
>> Thanks