[cfe-dev] libclang c API will not find c++ system headers

[Jacob Carlborg via cfe-dev]

On 2019-08-22 23:46, Per Bull Holmen via cfe-dev wrote:

> Thank you. I've tried running with the -v option now, and there is some
> difference. This might indicate that third-party plugin and tool
> developers should link to the Apple-provided libclang on macOS.
> 
> However, I'm not sure it's needed, as I did make it work with the
> precompiled binaries at http://releases.llvm.org/download.html simply by
> calling clang_parseTranslationUnit2FullArgv, and providing the path to
> the compiler executable in argv[0]. No extra steps necessary, no adding
> paths, and no change of compiler options beyond those supplied by Xcode
> (from the xcodebuild log).

Hmm, passing the path to the compiler executable in argv[0] instead of 
the tool sounds interesting. I haven't thought about that before. But I 
don't want my tool to require to have the compiler installed. On macOS 
it might not matter, but on Linux and Windows it's less likely that 
Clang is installed.

> I see some third-party developers of libclang-based plugins and tools
> struggle with this, so I tried to do the same thing with a more complex
> example and some Apple-specific system header includes that I know
> vim plugin devs have struggled with, more specifically umbrella headers
> in Apple Frameworks, and again it works smoothly right out of the box.
> No errors reported, and I can traverse the AST with no problems.
> 
> I've seen plugin devs do all sorts of hacks to work around issues that
> could have been solved this way, so I'd like to share a list of
> what I did to make it work, in the faint hope that other third party
> devs who run into the same problem read it:
> 
> 1) Make sure you load the libclang you expect, and not some arbitrary
> libclang the user might have in their system. Remember that you might
> link to one version at compile time, yet your tool or plugin loads a
> different version at runtime.

With my tool, I statically link libclang. I've got too many bug reports 
from users that have used an unsupported version of libclang.

> 2) Do not move libclang out of the clang+llvm distribution folder, or
> remove files that libclang expects to find there. It seems libclang
> expects to find certain files relative to the lib location.
> 
> 3) Use clang_parseTranslationUnit2FullArgv, and provide the path to the
> compiler executable in argv[0]. Interestingly, it made no difference in
> my case whether I used the one in the pre-compiled binaries folder
> downloaded at http://releases.llvm.org/download.html, or the one in
> Xcode's toolchain.
> 
> I suggest tools and plugins don't mangle with the command line options,
> like adding paths or remove -isysroot etc. unless they have tried
> everything above (and more), and it still doesn't work. Doing so creates
> all kinds of future compatibility issues, and breaks the invariant that
> users of your tool should always be able to depend on: If it works on
> the command line, with the same clang version, and exactly the same
> compiler options, then it should also work with your tool or plug-in.
> 
> I don't develop or maintain a cross-platform tool myself, so I can't
> guarantee that this invariant always holds for libclang itself,
> but I've seen cases where devs of such tools think they have to find
> workarounds when it could have been solved by the above steps, and
> haven't myself seen cases where it doesn't hold.

I have the SDK installed in the /usr directory as well, so both the 
Apple provided compiler and the on at provided by llvm.org will find the 
SDK.

-- 
/Jacob Carlborg