[cfe-dev] inconsistent header includes when using clang with -fmodules and CPATH is set

[Ken Cunningham via cfe-dev]

On MacPorts, we install headers and libraries in a non-standard subdirectory, usually /opt/local.

We set CPATH to accomplish this and it usually works well, except not with -fmodules set.

Things look like they should be OK:

$ CPATH=/opt/local/include cpp -v -fmodules
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.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.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -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 -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0 -I /usr/include -I/opt/local/include -fdebug-compilation-dir /Users/cunningh -ferror-limit 19 -fmessage-length 245 -stack-protector 1 -fblocks -fencode-extended-block-signature -fmodules -fimplicit-module-maps -fmodules-cache-path=/var/folders/r3/82p666c95kjgzc4z9fj3pdwr0000gn/C/org.llvm.clang.cunningh/ModuleCache -fmodules-validate-system-headers -fobjc-runtime=macosx-10.13.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c -
clang -cc1 version 10.0.0 (clang-1000.11.45.5) default target x86_64-apple-darwin17.7.0
ignoring duplicate directory "/usr/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/include
 /usr/local/include
 /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
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)


But in practice, we see errors like this:

In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/ncurses.h:141:
/opt/local/include/unctrl.h:60:63: error: unknown type name 'SCREEN'
NCURSES_EXPORT(NCURSES_CONST char *) NCURSES_SP_NAME(unctrl) (SCREEN*, chtype);

What happens is clang looks into the SDK first, finds ncurses.h in there, but that then calls into the unctrl.h in the CPATH path, and the build fails as the ncurses in the SDK is version 5, but MacPorts is version 6. 

I suspect this is happening more often than just this example, but this is the one that delivers our errors.

Should clang not use the fmodules-cache if CPATH is set?

Any ideas or workarounds for us would be much appreciated.

Ken Cunningham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200326/0a6d05ca/attachment.html>