Controlling usage of libc++ headers installed alongside the compiler

If you’re building with -stdlib=libc++, the Linux toolchain (which is used for e.g. Android) prefers libc++ headers installed alongside the compiler to those in the sysroot: https://github.com/llvm/llvm-project/blob/d5f7196feb7da50564c5ad444f5fd3fecf08f340/clang/lib/Driver/ToolChains/Linux.cpp#L892. I have a use case where this doesn’t work: the Android NDK’s version of libc++ uses a different inline namespace, so I want to pair it with the corresponding headers from the sysroot, even though my toolchain also contains libc++ headers (for use with other platforms).

I’m looking for a way to turn off searching for libc++ headers installed alongside the compiler but still search for them in the sysroot. The closest I can get right now is building with -nostdinc++ and adding a manual -isystem for the sysroot’s libc++ header directory, but that breaks compiles that want to use -nostdinc++ themselves and specify an alternate libc++ header location (since my -isystem will always be present, so you’ll end up with two copies of the libc++ headers in your search paths and everything will break).

I can think of two ways to accomplish this. One is to add a new flag (and I’m looking for naming suggestions for this flag) to turn off searching for libc++ headers installed alongside the compiler. The other is to promote -cxx-isystem to a driver option, inhibit any -cxx-isystem paths from being added to the search paths when -nostdinc++ is passed, and make sure -cxx-isystem gets put on the include path before everything else (since C++ headers usually #include_next into other system headers). What’s the best option here?

Hi Shoaib,

We have a similar problem in Chrome OS SDK ( https://bugs.chromium.org/p/chromium/issues/detail?id=948440 )
where we have libc++ headers installed for use in host while there are target specific libc++ headers installed in
different locations. The host headers are picked even though we specify --sysroot to point to target builds.

This hasn’t been a major problem for us though since libc++ headers are identical as long we
use the same version of libc++.

As for the choices: My preference is for a new flag but don’t have a naming preference.

Thanks,
Manoj