Pull request 1113 in include-what-you-use: fix: Don't always pull MacOs libcxx's header

58 views
Skip to first unread message

notifi...@include-what-you-use.org

unread,
Sep 19, 2022, 1:44:51 PM9/19/22
to include-wh...@googlegroups.com
New pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Nix try hard to isolate tools to ensure reproducibility: It will use a libcxx under his control. On darwin iwyu see two libcxx and get confused so this PR allow to become optional

For further context https://github.com/NixOS/nixpkgs/issues/189753#issuecomment-1251200266


notifi...@include-what-you-use.org

unread,
Sep 25, 2022, 9:49:37 AM9/25/22
to include-wh...@googlegroups.com
Comment #1 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

I wonder if we should just remove that code altogether... I happen to have a couple of Macs I can experiment with now, so I'll install Xcode on one and not the other and try to see what the difference is. It seems to me it's better to let Xcode users pass in those additional paths themselves.


notifi...@include-what-you-use.org

unread,
Sep 27, 2022, 6:49:56 PM9/27/22
to include-wh...@googlegroups.com
Comment #2 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

I didn't checked but if run under xcrun does those header get automatically added ? It would be a better design imo: let user choose his sdk, easily customisable (and should be part of his workflow ?)


notifi...@include-what-you-use.org

unread,
Sep 28, 2022, 12:54:51 PM9/28/22
to include-wh...@googlegroups.com
Comment #3 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Nice, I didn't know about xcrun. I'll run some experiments.


notifi...@include-what-you-use.org

unread,
Sep 30, 2022, 8:25:34 PM9/30/22
to include-wh...@googlegroups.com
Comment #4 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Just for the record:
```
$ env -u _ > /tmp/a
$ xcrun env -u _ > /tmp/b
$ diff /tmp/[ab]
11c11
< __CF_USER_TEXT_ENCODING=0x0:0:1
---
> __CF_USER_TEXT_ENCODING=0x1F6:0x0:0x1
29a30,32
> SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
> CPATH=/usr/local/include
> LIBRARY_PATH=/usr/local/lib
$ xcrun /bin/sh -c 'echo "$SDKROOT"/usr/include/c++/v1/'
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/
$ xcrun /bin/sh -c 'cat "$SDKROOT"/usr/include/c++/v1/__libcpp_version'; cat /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__libcpp_version /Library/Developer/CommandLineTools/usr/include/c++/v1/__libcpp_version
13000
11000
14000
```

So it seem using SDKROOT we get a more recent version of libcpp from Xcode. I have multiple copy because I first installed cli then later added Xcode. The version in the cli is 14 beta 3. Here we could be causing error because 2 differents libcpp are both installed and version mismatch.
IIRC `xcrun` can be modified with `xcode-select`


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 6:58:36 AM10/1/22
to include-wh...@googlegroups.com
Comment #5 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Thanks! I finally got around to compare four different setups:

* Homebrew Clang 14 on a machine without Xcode installed
* Apple Clang 14 on a machine with Xcode installed
* Homebrew Clang 14 on a machine with Xcode installed
* include-what-you-use built based on Homebrew Clang 14 on a machine with Xcode installed

I then ran `$cmd -fsyntax-only -v x.cc` where `x.cc` is an empty source file, to get the different tools to print their respective include paths and sysroot defaults.

**Homebrew Clang 14 on a machine without Xcode installed**:
```
$ /opt/homebrew/opt/llvm\@14/bin/clang -v -fsyntax-only x.cc
Homebrew clang version 14.0.6
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm@14/bin
(in-process)

"/opt/homebrew/Cellar/llvm@14/14.0.6/bin/clang-14" -cc1 -triple arm64-apple-macosx12.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name x.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -funwind-tables=2 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -target-cpu apple-m1 -target-feature +v8.5a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +dotprod -target-feature +fp16fml -target-feature +ras -target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-feature +sha2 -target-feature +aes -target-abi darwinpcs -fallow-half-arguments-and-returns -mllvm -treat-scalable-fixed-err
or-as-warning -debugger-tuning=lldb -target-linker-version 819.6 -v -fcoverage-compilation-dir=.../iwyu/include-what-you-use -resource-dir /opt/homebrew/Cellar/llvm@14/14.0.6/lib/clang/14.0.6 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -stdlib=libc++ -internal-isystem /opt/homebrew/opt/llvm@14/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include -internal-isystem /opt/homebrew/Cellar/llvm@14/14.0.6/lib/clang/14.0.6/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include -fdeprecated-macro -fdebug-compilation-dir=.../iwyu/include-what-you-use -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c++ x.cc

clang -cc1 version 14.0.6 based upon LLVM 14.0.6 default target arm64-apple-darwin21.6.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/opt/homebrew/opt/llvm@14/bin/../include/c++/v1
/opt/homebrew/Cellar/llvm@14/14.0.6/lib/clang/14.0.6/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks (framework directory)
End of search list.
```

**Apple Clang 14 on a machine with Xcode installed**
```
$ clang -v -fsyntax-only x.cc
Apple clang version 14.0.0 (clang-1400.0.29.102)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

"/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple x86_64-apple-macosx12.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name x.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-strict-return -fno-rounding-math -funwind-tables=2 -target-sdk-version=12.3 -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -target-linker-version 819.6 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/14.0.0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -stdlib=libc++ -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/Comman
dLineTools/usr/lib/clang/14.0.0/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -Wno-cast-function-type -Wno-bitwise-instead-of-logical -fdeprecated-macro -fdebug-compilation-dir=.../iwyu/include-what-you-use -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-cxx-modules -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+messageToSel
fInClassMethodIdReturnType -clang-vendor-feature=+disableInferNewAvailabilityFromInit -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -mllvm -disable-aligned-alloc-awareness=1 -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c++ x.cc

clang -cc1 version 14.0.0 (clang-1400.0.29.102) default target x86_64-apple-darwin21.6.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
/Library/Developer/CommandLineTools/usr/lib/clang/14.0.0/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
```

**Homebrew Clang 14 on a machine with Xcode installed:**
```
$ /usr/local/opt/llvm@14/bin/clang -v -fsyntax-only x.cc
Homebrew clang version 14.0.6
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm@14/bin
(in-process)

"/usr/local/Cellar/llvm@14/14.0.6/bin/clang-14" -cc1 -triple x86_64-apple-macosx12.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name x.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=all -ffp-contract=on -fno-rounding-math -funwind-tables=2 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=lldb -target-linker-version 819.6 -v -fcoverage-compilation-dir=.../iwyu/include-what-you-use -resource-dir /usr/local/Cellar/llvm@14/14.0.6/lib/clang/14.0.6 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -stdlib=libc++ -internal-isystem /usr/local/opt/llvm@14/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/loc
al/include -internal-isystem /usr/local/Cellar/llvm@14/14.0.6/lib/clang/14.0.6/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include -fdeprecated-macro -fdebug-compilation-dir=.../iwyu/include-what-you-use -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c++ x.cc

clang -cc1 version 14.0.6 based upon LLVM 14.0.6 default target x86_64-apple-darwin21.6.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/opt/llvm@14/bin/../include/c++/v1
/usr/local/Cellar/llvm@14/14.0.6/lib/clang/14.0.6/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks (framework directory)
End of search list.
```

**include-what-you-use built based on Homebrew Clang 14 on a machine with Xcode installed**:
```
$ include-what-you-use -v x.cc
Homebrew clang version 14.0.6
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: .../iwyu/out/main/bin
ignoring nonexistent directory ".../iwyu/out/main/bin/../include/c++/v1"

clang invocation:
".../iwyu/out/main/bin/include-what-you-use" "-cc1" "-triple" "x86_64-apple-macosx12.0.0" "-Wundef-prefix=TARGET_OS_" "-Werror=undef-prefix" "-Wdeprecated-objc-isa-usage" "-Werror=deprecated-objc-isa-usage" "-fsyntax-only" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "x.cc" "-mrelocation-model" "pic" "-pic-level" "2" "-mframe-pointer=all" "-ffp-contract=on" "-fno-rounding-math" "-funwind-tables=2" "-fcompatibility-qualified-id-block-type-checking" "-fvisibility-inlines-hidden-static-local-var" "-target-cpu" "penryn" "-tune-cpu" "generic" "-mllvm" "-treat-scalable-fixed-error-as-warning" "-debugger-tuning=lldb" "-target-linker-version" "819.6" "-v" "-fcoverage-compilation-dir=.../iwyu/include-what-you-use" "-resource-dir" ".../iwyu/out/main/lib/clang/14.0.6" "-isysroot" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk" "-stdlib=libc++" "-internal-isystem" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/
include/c++/v1" "-internal-isystem" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include" "-internal-isystem" ".../iwyu/out/main/lib/clang/14.0.6/include" "-internal-externc-isystem" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include" "-fdeprecated-macro" "-fdebug-compilation-dir=.../iwyu/include-what-you-use" "-ferror-limit" "19" "-stack-protector" "1" "-fblocks" "-fencode-extended-block-signature" "-fregister-global-dtors-with-atexit" "-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" "-fmax-type-align=16" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x" "c++" "x.cc"

clang -cc1 version 14.0.6 based upon LLVM 14.0.6 default target x86_64-apple-darwin21.6.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1
.../iwyu/out/main/lib/clang/14.0.6/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/usr/include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks (framework directory)
End of search list.
```
Will follow up with comments/analysis in a separate comment.


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 7:07:24 AM10/1/22
to include-wh...@googlegroups.com
Comment #6 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Re `xcrun`, it seems like the only relevant thing it does here is set `SDKROOT`, which in turn is set as the sysroot by the Clang driver. It appears the `include-what-you-use` implicitly gets that behavior too by virtue of using some of the Clang driver setup code. I did not have `SDKROOT` set in my environment in the tests above, so there's also some other logic at play to find the sysroot.

I don't think we can require `include-what-you-use` users to prefix with `xcrun`, because IWYU is mostly executed by other tools (e.g. build systems, `iwyu_tool.py`, etc), where additional command interposition is complicated.

But looking at the `include-what-you-use` example above, it seems like it's already figured out the sysroot, and the relevant include paths for libc++. So it does look like our hard-coded include paths are redundant.

How does Nix perform its override? Does it explicitly pass a `-sysroot` or `-isysroot` argument? Or something else?


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 7:20:24 AM10/1/22
to include-wh...@googlegroups.com
Comment #6 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

$ include-what-you-use -v -fsyntax-only x.cc
Homebrew clang version 14.0.6
Target: x86_64-apple-darwin21.6.0
Thread model: posix

notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 7:39:06 AM10/1/22
to include-wh...@googlegroups.com
Comment #7 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

And here's a final run with IWYU built based on Homebrew Clang 14, on a Mac without Xcode:
```
$ bin/include-what-you-use -v ../x.cc
Homebrew clang version 14.0.6
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: .../iwyu/include-what-you-use/build/bin
ignoring nonexistent directory ".../iwyu/include-what-you-use/build/bin/../include/c++/v1"
clang invocation:
".../iwyu/include-what-you-use/build/bin/include-what-you-use" "-cc1" "-triple" "arm64-apple-macosx12.0.0" "-Wundef-prefix=TARGET_OS_" "-Werror=undef-prefix" "-Wdeprecated-objc-isa-usage" "-Werror=deprecated-objc-isa-usage" "-fsyntax-only" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "x.cc" "-mrelocation-model" "pic" "-pic-level" "2" "-mframe-pointer=non-leaf" "-ffp-contract=on" "-fno-rounding-math" "-funwind-tables=2" "-fcompatibility-qualified-id-block-type-checking" "-fvisibility-inlines-hidden-static-local-var" "-target-cpu" "apple-m1" "-target-feature" "+v8.5a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" "-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" "+dotprod" "-target-feature" "+fp16fml" "-target-feature" "+ras" "-target-feature" "+lse" "-target-feature" "+rdm" "-target-feature" "+rcpc" "-target-feature" "+zcm" "-target-feature" "+zcz" "-target-feature" "+fullfp16" "-target-fe
ature" "+sha2" "-target-feature" "+aes" "-target-abi" "darwinpcs" "-fallow-half-arguments-and-returns" "-mllvm" "-treat-scalable-fixed-error-as-warning" "-debugger-tuning=lldb" "-target-linker-version" "819.6" "-v" "-fcoverage-compilation-dir=.../iwyu/include-what-you-use/build" "-resource-dir" ".../iwyu/include-what-you-use/build/lib/clang/14.0.6" "-isysroot" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk" "-stdlib=libc++" "-internal-isystem" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1" "-internal-isystem" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include" "-internal-isystem" ".../iwyu/include-what-you-use/build/lib/clang/14.0.6/include" "-internal-externc-isystem" "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include" "-fdeprecated-macro" "-fdebug-compilation-dir=.../iwyu/include-what-you-use/build" "-ferror-limit" "19" "-stack-protector" "1" "-fblocks" "-fencode-extended-block-signature" "-fregister-global-
dtors-with-atexit" "-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" "-fmax-type-align=16" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x" "c++" "../x.cc"

clang -cc1 version 14.0.6 based upon LLVM 14.0.6 default target arm64-apple-darwin21.6.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1
.../iwyu/include-what-you-use/build/lib/clang/14.0.6/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/usr/include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks (framework directory)
End of search list.
```
It appears I have a MacOS SDK on that machine anyway, so probably that counts as a sysroot.


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 7:45:39 AM10/1/22
to include-wh...@googlegroups.com
Comment #8 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

The bug report/discussion that led up to the hard-coded libc++ paths was also relevant: https://github.com/include-what-you-use/include-what-you-use/issues/247. It could be that Clang has improved over the years to make the special handling redundant.


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 9:05:39 AM10/1/22
to include-wh...@googlegroups.com
Comment #9 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

> How does Nix perform its override? Does it explicitly pass a `-sysroot` or `-isysroot` argument? Or something else?

Nix create a wrapper that add compiler flags. Here is the main file.

https://github.com/NixOS/nixpkgs/blob/c153b8104c3e63f9ff07001453fd934df6877118/pkgs/build-support/cc-wrapper/cc-wrapper.sh#L198

file are generated depending on libc used: https://github.com/NixOS/nixpkgs/blob/8ba120420fbdd9bd35b3a5366fa0206d8c99ade3/pkgs/build-support/cc-wrapper/default.nix#L376-L379


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 10:23:38 AM10/1/22
to include-wh...@googlegroups.com
Comment #10 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Thanks. It's hard to reason about that without knowing more about Nix. How do you suppose it avoids the implicit sysroot headers that Clang always adds?

Could you show the output of `clang -fsyntax-only -v x.cc` and `include-what-you-use -v x.cc` with an empty `x.cc`, under Nix? It's not really clear to me what it does -- does that cc-wrapper get applied to all compile-commands?


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 11:41:19 AM10/1/22
to include-wh...@googlegroups.com
Comment #11 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

If you want to test you can drop this in `shell.nix`:
```nix
let
pkgs = import <nixpkgs> {};
in
pkgs.mkShell.override { stdenv = pkgs.llvmPackages_14.stdenv; } {
nativeBuildInputs = [
pkgs.which
pkgs.include-what-you-use
pkgs.file
];
shellHooks = ''
demo() {
cat > x.cc <<EOF
EOF
set -x
file -L $(which -a clang include-what-you-use)
clang -fsyntax-only -v x.cc
include-what-you-use -v x.cc
set +x
}
'';
}
```

`nix-shell --pure` drop you in a shell with only the tools listed.

`--run` is like `-c` of bash

`nix-shell --pure --run demo`:
```
$ nix-shell --pure --run demo
++ which -a clang include-what-you-use
+ file -L /nix/store/d3qqr2xfl4rjnilpb89gdgzby3w6nna8-clang-wrapper-14.0.1/bin/clang /nix/store/mcf81m51paaxi866phzcbsnvkv2ccfx7-clang-14.0.1/bin/clang /nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/bin/include-what-you-use
/nix/store/d3qqr2xfl4rjnilpb89gdgzby3w6nna8-clang-wrapper-14.0.1/bin/clang: a /nix/store/zhb1b88lw5qxhk50f75dgfwwh5m0cg7i-bash-5.1-p16/bin/bash script, ASCII text executable
/nix/store/mcf81m51paaxi866phzcbsnvkv2ccfx7-clang-14.0.1/bin/clang: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|PIE>
/nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/bin/include-what-you-use: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|PIE>
+ clang -fsyntax-only -v x.cc
clang version 14.0.1
Target: x86_64-apple-darwin
Thread model: posix
InstalledDir: /nix/store/mcf81m51paaxi866phzcbsnvkv2ccfx7-clang-14.0.1/bin
clang-14: warning: -Wl,-no_uuid: 'linker' input unused [-Wunused-command-line-argument]
clang-14: warning: -Wl,-arch: 'linker' input unused [-Wunused-command-line-argument]
clang-14: warning: -Wl,x86_64: 'linker' input unused [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/kyy78xqvxn0ydlv2bq683vdydqlw8kif-file-5.41/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/rk28kk0cxxdwlsw6cskh3f8wfvhky657-libcxx-14.0.1/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/khl817k2m5dl02h85zdybx2s33x900km-libcxxabi-14.0.1/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/cb1vls7v8r73qpv5nqhfd4c6vlbzgk1r-compiler-rt-libc-14.0.1/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/kyy78xqvxn0ydlv2bq683vdydqlw8kif-file-5.41/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/rk28kk0cxxdwlsw6cskh3f8wfvhky657-libcxx-14.0.1/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/khl817k2m5dl02h85zdybx2s33x900km-libcxxabi-14.0.1/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/cb1vls7v8r73qpv5nqhfd4c6vlbzgk1r-compiler-rt-libc-14.0.1/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/w8yxxdl9w8sykxz8knjb7dxpzy97sq2g-clang-14.0.1-lib/lib' [-Wunused-command-line-argument]
clang-14: warning: argument unused during compilation: '-L/nix/store/rk28kk0cxxdwlsw6cskh3f8wfvhky657-libcxx-14.0.1/lib' [-Wunused-command-line-argument]
(in-process)
"/nix/store/mcf81m51paaxi866phzcbsnvkv2ccfx7-clang-14.0.1/bin/clang-14" -cc1 -triple x86_64-apple-macosx10.12.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name x.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=all -ffp-contract=on -fno-rounding-math -funwind-tables=2 -faligned-alloc-unavailable -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=lldb -target-linker-version 530 -v -fcoverage-compilation-dir=/private/tmp/bug2 -nostdsysteminc -resource-dir /nix/store/d3qqr2xfl4rjnilpb89gdgzby3w6nna8-clang-wrapper-14.0.1/resource-root -idirafter /nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include -isystem /nix/store/kyy78xqvxn0ydlv2bq683vdydqlw8kif-
file-5.41/include -isystem /nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include -isystem /nix/store/c01h79z45vz3vnyw7q5lp02518xrg81i-libcxxabi-14.0.1-dev/include -isystem /nix/store/m6jyriz5wn8ci5fv13l8w215dfll96zp-compiler-rt-libc-14.0.1-dev/include -iframework /nix/store/lbmhm3v63sn5bz0ackwp763cmh306n28-swift-corefoundation-unstable-2018-09-14/Library/Frameworks -isystem /nix/store/kyy78xqvxn0ydlv2bq683vdydqlw8kif-file-5.41/include -isystem /nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include -isystem /nix/store/c01h79z45vz3vnyw7q5lp02518xrg81i-libcxxabi-14.0.1-dev/include -isystem /nix/store/m6jyriz5wn8ci5fv13l8w215dfll96zp-compiler-rt-libc-14.0.1-dev/include -iframework /nix/store/lbmhm3v63sn5bz0ackwp763cmh306n28-swift-corefoundation-unstable-2018-09-14/Library/Frameworks -D _FORTIFY_SOURCE=2 -stdlib=libc++ -internal-isystem /nix/store/d3qqr2xfl4rjnilpb89gdgzby3w6nna8-clang-wrapper-14.0.1/resource-root/include -O2 -Wformat -Wformat-security -Wer
ror=format-security -fdeprecated-macro -fdebug-compilation-dir=/private/tmp/bug2 -ferror-limit 19 -fwrapv -stack-protector 2 -stack-protector-buffer-size 4 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -vectorize-loops -vectorize-slp -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c++ x.cc
clang -cc1 version 14.0.1 based upon LLVM 14.0.1 default target x86_64-apple-darwin21.5.0
ignoring duplicate directory "/nix/store/kyy78xqvxn0ydlv2bq683vdydqlw8kif-file-5.41/include"
ignoring duplicate directory "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include"
ignoring duplicate directory "/nix/store/c01h79z45vz3vnyw7q5lp02518xrg81i-libcxxabi-14.0.1-dev/include"
ignoring duplicate directory "/nix/store/m6jyriz5wn8ci5fv13l8w215dfll96zp-compiler-rt-libc-14.0.1-dev/include"
ignoring duplicate directory "/nix/store/lbmhm3v63sn5bz0ackwp763cmh306n28-swift-corefoundation-unstable-2018-09-14/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/nix/store/kyy78xqvxn0ydlv2bq683vdydqlw8kif-file-5.41/include
/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include
/nix/store/c01h79z45vz3vnyw7q5lp02518xrg81i-libcxxabi-14.0.1-dev/include
/nix/store/m6jyriz5wn8ci5fv13l8w215dfll96zp-compiler-rt-libc-14.0.1-dev/include
/nix/store/lbmhm3v63sn5bz0ackwp763cmh306n28-swift-corefoundation-unstable-2018-09-14/Library/Frameworks (framework directory)
/nix/store/d3qqr2xfl4rjnilpb89gdgzby3w6nna8-clang-wrapper-14.0.1/resource-root/include
/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include
End of search list.
+ include-what-you-use -v x.cc
clang version 14.0.1
Target: x86_64-apple-darwin21.5.0
Thread model: posix
InstalledDir: /nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/bin
clang invocation:
"/nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/bin/include-what-you-use" "-cc1" "-triple" "x86_64-apple-macosx10.12.0" "-Wundef-prefix=TARGET_OS_" "-Werror=undef-prefix" "-Wdeprecated-objc-isa-usage" "-Werror=deprecated-objc-isa-usage" "-fsyntax-only" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "x.cc" "-mrelocation-model" "pic" "-pic-level" "2" "-mframe-pointer=all" "-ffp-contract=on" "-fno-rounding-math" "-funwind-tables=2" "-faligned-alloc-unavailable" "-fcompatibility-qualified-id-block-type-checking" "-fvisibility-inlines-hidden-static-local-var" "-target-cpu" "penryn" "-tune-cpu" "generic" "-mllvm" "-treat-scalable-fixed-error-as-warning" "-debugger-tuning=lldb" "-target-linker-version" "530" "-v" "-fcoverage-compilation-dir=/private/tmp/bug2" "-nostdsysteminc" "-resource-dir" "/nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/lib/clang/14.0.1" "-stdlib=libc++" "-intern
al-isystem" "/nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/lib/clang/14.0.1/include" "-fdeprecated-macro" "-fdebug-compilation-dir=/private/tmp/bug2" "-ferror-limit" "19" "-stack-protector" "1" "-fblocks" "-fencode-extended-block-signature" "-fregister-global-dtors-with-atexit" "-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" "-fmax-type-align=16" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x" "c++" "x.cc"

clang -cc1 version 14.0.1 based upon LLVM 14.0.1 default target x86_64-apple-darwin21.5.0
ignoring nonexistent directory "/nix/store/fdzi7lvlrkc49wk8aqzj1qim554bqi34-include-what-you-use-0.18/lib/clang/14.0.1/include"
#include "..." search starts here:
#include <...> search starts here:
/Library/Developer/CommandLineTools/usr/include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
End of search list.

(x.cc has correct #includes/fwd-decls)
+ set +x
```

We have two clang in path one is the wrapper script that add flag for the other clang. iwyu doesn't have one I tried to add one but then it failed because a mismatch of libcpp (one added with wrapper and one from my system).


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 12:05:18 PM10/1/22
to include-wh...@googlegroups.com
Comment #12 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Nice, thanks. It looks like Nix isolates Clang sufficiently that it can't find a sysroot with Xcode/MacOS SDK headers. That's cool, that means `include-what-you-use` should follow the same behavior.

I think the best approach is actually to remove the special hard-coded paths unconditionally in IWYU, but I want to try that with a few different setups before I commit to it. Thanks for helping investigate this!


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 3:31:02 PM10/1/22
to include-wh...@googlegroups.com
Comment #13 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

I've experimented a bit. Curious about one thing: I've run clang and IWYU with `/Library/Developer/CommandLineTools` temporarily removed, which means there are no MacOS system headers available. For this input:
```
// x.cc
#include <string>
```
that causes both to fail with:
```
..
/usr/local/opt/llvm@14/bin/../include/c++/v1/wchar.h:123:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
```
Do you know how Nix makes `<wchar.h>` and other system headers available?


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 3:36:44 PM10/1/22
to include-wh...@googlegroups.com
Comment #14 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

They also come with LibSystem compiled from apple-oss:
```
$ nix-shell --pure --run 'clang++ -E x.cc | grep wchar.h'
# 1 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 1 3
# 109 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 3
# 110 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 2 3
# 117 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 3
# 1 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 1 3
# 70 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 3
# 71 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 73 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 75 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 76 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 77 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 78 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 79 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 80 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 89 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 3
# 90 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 91 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 92 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 93 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 2 3
# 169 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 3
# 194 "/nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include/wchar.h" 3
# 124 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 2 3
# 139 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 3
# 1 "/nix/store/a65wkr5w6vclj3kv273s6wim9m84srmf-libcxx-14.0.1-dev/include/c++/v1/wchar.h" 1 3
```


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 3:39:19 PM10/1/22
to include-wh...@googlegroups.com
[Here](https://github.com/include-what-you-use/include-what-you-use/pull/1113#issuecomment-1264401473) we can read
`-idirafter /nix/store/wqbmlhl40i4c4w6mlq4dihwkbxzvhxwa-Libsystem-1238.60.2/include`


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 4:00:58 PM10/1/22
to include-wh...@googlegroups.com
Comment #15 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Cool, thanks. In that case it should work perfectly fine for your use case to remove the hard-coded include paths.

It's a little trickier for Homebrew packaging, which should depend on the llvm@vv libc++ header path. That path is not known when iwyu is built.

But I think the way Homebrew iwyu currently relies on the CommandLineTools headers is also broken, it just happens to work most of the time.

So I suggest you update this patch to unconditionally remove the paths, and we'll have to think of a good way to enable Homebrew packaging.


notifi...@include-what-you-use.org

unread,
Oct 1, 2022, 9:41:54 PM10/1/22
to include-wh...@googlegroups.com
Comment #16 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

> we'll have to think of a good way to enable Homebrew packaging.

I can invert the patch.

PRO:
Homebrew will show explicit dependencies (and if they have a package like nix Libsystem then they can redirect to their own)

CON:
might break macports ? fink ? and other packages manager that target MacOS ? (They just have to make it explicit that they require DevelopperTools libcpp)


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 9:08:31 AM10/3/22
to include-wh...@googlegroups.com
Comment #17 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

@Et7f3 I think I'd rather just get rid of the hard-coded paths for now, since having IWYU inject something that causes conflicts is actively disruptive. Missing include paths for some systems is a missing feature, and can be worked around with `-isystem`.

I think the next logical step is to make extra paths configurable from CMake, so that packagers can pick and choose which libc++ they want to use. I _think_ that might work for Homebrew -- add a dependency on llvm@NN, and build IWYU so it adds llvm@NN's libc++ include path. I don't know if it's possible to override install location with Homebrew; that would make this a no-go.

But I really don't know how that problem can be solved nicely; something needs to happen at runtime to locate all possible providers of system headers, libc++ headers (and actually, Clang resource headers). That seems like an open-ended problem to me, but maybe it would be possible to start with the ones we know about right now.

At any rate, that has nothing to do with the Nix problem -- I think we're OK with removing the hard-coded headers for now. On both my Mac environments, the relevant paths were added anyway because the Clang code picked up the MacOS SDKs.


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 9:25:29 AM10/3/22
to include-wh...@googlegroups.com
Comment #18 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Ok updated 👍


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 10:38:21 AM10/3/22
to include-wh...@googlegroups.com
Comment #19 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Thanks!

I thought I'd rewrite the commit message to:
```
Don't force pull MacOS SDK libcxx's header

As a fix for issue #247 we added a block of hard-coded paths to the
include search path, which would find libc++ from the MacOS SDK.

While the MacOS SDK is usually present where IWYU is run, on developer
machines, there may be any number of other sysroots providing libc++
that users would prefer to use.

The Nix tool is one such player, where builds are isolated and all
dependencies are gathered in a single root for reproducibility.

Recent experiments with Clang on different Mac systems show that:

* if the MacOS SDK is present, IWYU picks it up automatically via the
Clang driver
* if the MacOS SDK is not present, no include paths are conjured out of
thin air
* Clang installed from Homebrew llvm package finds the libc++ also
provided as part of that package

So it seems only IWYU forcefully adds magic paths, and it causes problem
for folks who want to do the right thing and build the sysroot
themselves.

Remove the hard-coded paths for now.

Users who wish to use a non-SDK libc++ should still be able to do so
using:

-isystem .../usr/include/c++/v1
-isystem .../clang/14.0.0/include
-isystem .../usr/include

on the command-line
```

to give some more context and workarounds for people who may be hurt by the change. Does it look good to you?


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 4:32:12 PM10/3/22
to include-wh...@googlegroups.com
Comment #20 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

Adding -isystem = the path deleted as example could be good to exactly restore the behavior.

Otherwise looks fine. I usually see GitHub ui to find discussion about commit/PR but you did a good job at summarizing.


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 5:32:08 PM10/3/22
to include-wh...@googlegroups.com
Comment #21 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

> Adding -isystem = the path deleted as example could be good to exactly restore the behavior.

I didn't quite understand this -- did you mean it would be useful to maintain the full paths? The point I was trying to make was that Clang's driver code (which is used by iwyu) already seems to pick those paths up nicely, so there's no need to repeat them. It's more useful for other cases, such as Homebrew or Nix, each of which have their own sysroots. But I don't have a good stable idea of where they put their files, so I don't want to commit it to history 🙂


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 5:41:19 PM10/3/22
to include-wh...@googlegroups.com
Comment #21 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

> Adding -isystem = the path deleted as example could be good to exactly restore the behavior.

I didn't quite understand this -- did you mean it would be useful to maintain the full paths in the -isystem examples? The point I was trying to make was that Clang's driver code (which is used by iwyu) already seems to pick those paths up nicely, so there's no need to repeat them. It's more useful for other cases, such as Homebrew or Nix, each of which have their own sysroots. But I don't have a good stable idea of where they put their files, so I don't want to commit it to history 🙂


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 10:56:01 PM10/3/22
to include-wh...@googlegroups.com
Comment #22 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

> > Adding -isystem = the path deleted as example could be good to exactly restore the behavior.
>
> I didn't quite understand this -- did you mean it would be useful to maintain the full paths in the -isystem examples? The point I was trying to make was that Clang's driver code (which is used by iwyu) already seems to pick those paths up nicely, so there's no need to repeat them. It's more useful for other cases, such as Homebrew or Nix, each of which have their own sysroots. But I don't have a good stable idea of where they put their files, so I don't want to commit it to history 🙂

I would add something like:

If you rely on this old behavior you can add:
-isystem "/Library/Developer/CommandLineTools/usr/include/c++/v1/" -isystem "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1"


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 10:57:26 PM10/3/22
to include-wh...@googlegroups.com
Comment #22 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

> > Adding -isystem = the path deleted as example could be good to exactly restore the behavior.
>
> I didn't quite understand this -- did you mean it would be useful to maintain the full paths in the -isystem examples? The point I was trying to make was that Clang's driver code (which is used by iwyu) already seems to pick those paths up nicely, so there's no need to repeat them. It's more useful for other cases, such as Homebrew or Nix, each of which have their own sysroots. But I don't have a good stable idea of where they put their files, so I don't want to commit it to history 🙂

I would add something like:
```
If you rely on this old behavior it can be replicated with theses flags:
-isystem "/Library/Developer/CommandLineTools/usr/include/c++/v1/" -isystem "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1"
```


notifi...@include-what-you-use.org

unread,
Oct 3, 2022, 10:59:58 PM10/3/22
to include-wh...@googlegroups.com

notifi...@include-what-you-use.org

unread,
Oct 6, 2022, 4:22:51 PM10/6/22
to include-wh...@googlegroups.com
Comment #23 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

What is the issue now that we need to fix ?


notifi...@include-what-you-use.org

unread,
Oct 6, 2022, 4:23:03 PM10/6/22
to include-wh...@googlegroups.com
Comment #23 on pull request 1113 by Et7f3: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

What is now the issue we need to fix ?


notifi...@include-what-you-use.org

unread,
Oct 6, 2022, 4:33:23 PM10/6/22
to include-wh...@googlegroups.com
Comment #24 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

I'm working on the commit message, but I've been busy with other things the past few days. I'll get this merged as soon as I have a block of spare time available.


notifi...@include-what-you-use.org

unread,
Oct 8, 2022, 5:59:39 AM10/8/22
to include-wh...@googlegroups.com
Comment #25 on pull request 1113 by kimgr: fix: Don't always pull MacOs libcxx's header
https://github.com/include-what-you-use/include-what-you-use/pull/1113

And merged. Thank you for the support!


Reply all
Reply to author
Forward
0 new messages