[LLVMbugs] [Bug 17776] New: libclang does not get the header search correct

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=17776

            Bug ID: 17776
           Summary: libclang does not get the header search correct
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jgunthorpe at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For instance, if we run one of the included python tests using the raw build
directory from cmake+ninja:

$ LD_LIBRARY_PATH=/scratchl/jgg/llvm/build/lib/
PYTHONPATH=/scratchl/jgg/llvm/tools/clang/bindings/python 
python
/scratchl/jgg/llvm/tools/clang/bindings/python/examples/cindex/cindex-dump.py
t.c -v

Here! ../tools/clang/lib/Driver/Driver.cpp:68 Dir=
clang version 3.4 
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Here! ../tools/clang/lib/Frontend/ASTUnit.cpp:2038
ResourceFilesPath=/scratchl/jgg/llvm/build/lib/clang/3.4
ignoring nonexistent directory "../lib/clang/3.4/include"

The 'ignoring nonexistent directory' line shows the wrong path, it should be
prefixed with the bin dir. Eg when running clang natively that doesn't print
and the search path properly includes:

/scratchl/jgg/llvm/build/bin/../lib/clang/3.4/include

Which is missing from the libclang version.

This problem causes parses through libclang to fail, typically with cannot find
stddef.h warnings.

I've edited the source (using GIT as of today) and added some Here! prints to
show some of the flow.

Analysis:

libclang uses the code in CIndexer::getClangResourcesPath() to locate the
installation relative to the shared library location. This code is working
fine, the 2nd Here! above prints the result of that function as it shows up in
ASTUnit::LoadFromCommandLine as ResourceFilesPath

However, the value ResourceFilesPath is no longer used on Linux because
InitHeaderSearch::AddDefaultIncludePaths exits early. On Linux the include
files are found via the Driver constructor's ClangExecutable argument, which is
wired to 'clang' when libclang is being used.

Which is because of this code in clang::createInvocationFromCommandLine

  // FIXME: We shouldn't have to pass in the path info.
  driver::Driver TheDriver("clang", llvm::sys::getDefaultTargetTriple(),
                           "a.out", *Diags);

The driver should probably be created with something like ResourceFilesPath +
"../bin/clang" until the FIXME is solved properly..

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131101/e656137b/attachment.html>