Yes, it's expected -- there was some discussion about this upstream a few years ago and the Apple folks said that this is how they like it. You need to pass `-isysroot $(xcrun -show-sdk-path)` for this to work.

I couldn't compile even if I pass `-isysroot $(xcrun -show-sdk-path)`.


tikuta-macbookpro:bin tikuta$ echo '#include <iostream>' > test.cc
tikuta-macbookpro:bin tikuta$ ./clang++ -isysroot $(xcrun -show-sdk-path) -c -o /dev/null -v test.cc
clang version 8.0.0 (trunk 349417)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin/.
 "/Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -main-file-name test.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-sdk-version=10.14 -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -ggnu-pubnames -target-linker-version 302.3 -v -coverage-notes-file /dev/null.gcno -resource-dir /Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/lib/clang/8.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -stdlib=libc++ -internal-isystem /Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin/include/c++/v1 -fdeprecated-macro -fdebug-compilation-dir /Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin -ferror-limit 19 -fmessage-length 204 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fobjc-runtime=macosx-10.14.0 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /dev/null -x c++ test.cc
clang -cc1 version 8.0.0 based upon LLVM 8.0.0svn default target x86_64-apple-darwin18.2.0
ignoring nonexistent directory "/Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/lib/clang/8.0.0/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)
End of search list.
test.cc:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.
tikuta-macbookpro:bin tikuta$ xcrun -show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
tikuta-macbookpro:bin tikuta$ pwd
/Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin



If I use Mac's xcode clang, I can compile test.cc.


tikuta-macbookpro:bin tikuta$ clang++ -isysroot $(xcrun -show-sdk-path) -c -o /dev/null -v test.cc
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 409.12 -v -coverage-notes-file /dev/null.gcno -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin -ferror-limit 19 -fmessage-length 204 -stack-protector 1 -fblocks -fencode-extended-block-signature -fobjc-runtime=macosx-10.14.0 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /dev/null -x c++ test.cc
clang -cc1 version 10.0.0 (clang-1000.11.45.2) default target x86_64-apple-darwin18.2.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks (framework directory)
End of search list.

Ah wait, on mac we put the libc++ headers in the clang package so that they are found by default. Does `find third_party/llvm-build/Release+Asserts -name iostream` find the file? It's supposed to be in include/c++/v1.

Yes, it finds iostream.

tikuta-macbookpro:src tikuta$ find third_party/llvm-build/Release+Asserts -name iostream
third_party/llvm-build/Release+Asserts/include/c++/v1/iostream

But, clang seems to search wrong directory.
> ignoring nonexistent directory "/Users/tikuta/chromium/src/third_party/llvm-build/Release+Asserts/bin/include/c++/v1"

Hmmm! Do older clangs from https://is.gd/chromeclang work? Maybe the path search logic changed at some point and we didn't update the package script?

The chrome build seems to be happy, in any case.

This behavior change seems to happen clang updated in
https://chromium-review.googlesource.com/c/chromium/src/+/1382232

Maybe due to this:


r346652 | ibiryukov | 2018-11-12 08:55:55 -0500 (Mon, 12 Nov 2018) | 27 lines

Make clang-based tools find libc++ on MacOS

Summary:
When they read compiler args from compile_commands.json.
This change allows to run clang-based tools, like clang-tidy or clangd,
built from head using the compile_commands.json file produced for XCode
toolchains.

On MacOS clang can find the C++ standard library relative to the
compiler installation dir.

The logic to do this was based on resource dir as an approximation of
where the compiler is installed. This broke the tools that read
'compile_commands.json' and don't ship with the compiler, as they
typically change resource dir.

To workaround this, we now use compiler install dir detected by the driver
to better mimic the behavior of the original compiler when replaying the
compilations using other tools.

Reviewers: sammccall, arphaman, EricWF

Reviewed By: sammccall

Subscribers: ioeric, christof, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D54310




? ibiryukov, do we need to package libc++ headers after that? Is that an intentional side effect?

Actually, let me ask on the cfe-commits commit instead.

Asked here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190107/256766.html

https://reviews.llvm.org/D56446 will hopefully fix this.

Thanks!

Landed in upstream r350714

rolled clang 350768-1
https://chromium.googlesource.com/chromium/src/+/54a0c3d18cced2cfe0a32edec204de840f80d596

is this fixed?

Testing in
https://chrome-internal-review.googlesource.com/c/goma/client/+/783888

Thank you for fix!