[cfe-dev] Inconsistent libc++ search paths

[Dan Albert via cfe-dev]

Maybe the reason they differ is so you get new libc++ headers but still use
the system dylib by default on Mac? I know that's a use case that's fairly
carefully maintained, but idk if it's intended to be the default.

>From the NDK side of things, changing the libc++ header search to match the
libc++ library search should be fine.

On Fri, Feb 22, 2019 at 3:20 PM Evgenii Stepanov <eugeni.stepanov at gmail.com>
wrote:

> Hi,
>
> in lib/Driver/ToolChains/Linux.cpp, the search order for libc++
> headers and libraries seems inconsistent.
>
> Headers are searched in
> 1. Resource dir
> 2. Driver dir
> 3. %sysroot/usr/include/c++
>
> Libraries are searched in
> 1. Driver dir only if it is under sysroot (!)
> 2. %sysroot/lib
> 3. %sysroot/usr/lib
>
> When building with what Linux::addLibCxxIncludePaths calls
> "development, non-installed" clang and a sysroot (ex. I'm using one
> from Android NDK) where both locations have a copy of libc++, clang
> picks libc++ headers from its resource dir, and an incompatible
> library from sysroot.
>
> Comments around the library search code suggest that the order should
> not be changed. Does it make sense to tweak the headers search order
> to match? That way building with local libc++ and a sysroot would
> require extra flags (because clang would default to sysroot headers),
> but that is already the case for the -shared-libc++ case.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190222/03d7c6ae/attachment.html>