Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libclang can not find the builtin includes. #238

Closed
Urich opened this issue Jan 17, 2013 · 58 comments
Closed

Libclang can not find the builtin includes. #238

Urich opened this issue Jan 17, 2013 · 58 comments

Comments

@Urich
Copy link

Urich commented Jan 17, 2013

After open cpp file i did see message "WARNING: libclang can not find the builtin includes." etc. I did find wrong in function "getBuiltinHeaderPath". I did replace value path (library_path + "/../lib/clang") on this "library_path + "/../clang""
Value is library_path = /usr/lib/llvm

ps. Linux 3.3.8-gentoo

@tobiasgrosser
Copy link
Collaborator

Can you rewrite the function like this:

def getBuiltinHeaderPath(library_path):
  path = library_path + "/../lib/clang"
  try:
    files = os.listdir(path)
  except:
    return None

  files = sorted(files)
  path = path + "/" + files[-1] + "/include/"
  arg = "-I" + path
  if canFindBuiltinHeaders(index, [arg]):
    return path

  if canFindBuiltinHeaders(index, "/usr/lib/llvm")
    return path
  return None

If this works, you may submit a pull request that adds this change to clang_complete.

@ismail
Copy link

ismail commented Jan 18, 2013

Hardcoding "lib" is not correct, on openSUSE 64bit the headers are in /usr/lib64/clang//include

@tobiasgrosser
Copy link
Collaborator

We don't hardcode here. We search at different (known) locations. Do you have a suggestion how we could do better?
The only other option I see is to call clang (and hope that it is the right one) and ask it to provide this information

@ismail
Copy link

ismail commented Jan 18, 2013

Ah sorry, I meant something like this

knownPaths = ["/usr/lib/clang","/usr/lib64/clang","/usr/lib/llvm"]
for path in knownPaths:
    if canFindBuiltinHeaders(index, path):
        return path

return None

@Urich
Copy link
Author

Urich commented Jan 19, 2013

tobig. This function does not work. Because in line "files = os.listdir(path)" path not exist.

@tobiasgrosser
Copy link
Collaborator

What about this patch: tobiasgrosser@6cc2dd6

@Urich
Copy link
Author

Urich commented Jan 19, 2013

def getBuiltinHeaderPath(library_path):
  know_paths = [library_path + "/../lib/clang", library_path + "/../lib64/clang", library_path + "/../clang"]
  for path in know_paths:
    try:
      clang_path = os.listdir(path)
      break
    except :
      pass

!!! Here do something if all path not exist

  clang_path = sorted(clang_path)
  path = path + "/" + clang_path[-1] + "/include/"
  arg = "-I" + path
  if canFindBuiltinHeaders(index, [arg]):
    return path

  return None

This code works for me.

@Urich
Copy link
Author

Urich commented Jan 19, 2013

def getBuiltinHeaderPath(library_path):
  path = library_path + "/../lib/clang"
  try:
    files = os.listdir(path)
    files = sorted(files)
    path = path + "/" + files[-1] + "/include/"
    arg = "-I" + path
    if canFindBuiltinHeaders(index, [arg]):
      return path
  except:
    pass

  knownPaths = [
    "/usr/lib/clang/3.2/include/", # Gentoo
    "/usr/lib64/clang/include" # OpenSuse 64 bit
  ]

  for path in knownPaths:
    arg = "-I" + path
    if canFindBuiltinHeaders(index, [arg]):
        return path

  return None

I some fix this patch. It's worked.

@Urich
Copy link
Author

Urich commented Jan 19, 2013

I have gentoo 64bit and clang 3.2

@tobiasgrosser
Copy link
Collaborator

@ulrich Thanks for testing. I added your changes to https://github.com/tobig/clang_complete/tree/known_builtin_headers . Does this branch now compile for you? If it does, I would like to submit as a pull request.

@ismail
Copy link

ismail commented Jan 19, 2013

This won't work on openSUSE because the correct path is clang version dependent, e.g /usr/lib64/clang/3.2/include

so I suggest this code

def getBuiltinHeaderPath(library_path):
  knownPaths = [library_path + "/../lib/clang", library_path + "/../lib64/clang" , "/usr/lib/llvm"]
  for path in knownPaths:
      try:
          files = os.listdir(path)
          files = sorted(files)
          path = path + "/" + files[-1] + "/include/"
          arg = "-I" + path
          if canFindBuiltinHeaders(index, [arg]):
              return path
      except:
          pass

  return None

@Urich
Copy link
Author

Urich commented Jan 20, 2013

def getBuiltinHeaderPath(library_path):
  path = library_path + "/../lib/clang"
  try:
    files = os.listdir(path)
    files = sorted(files)
    path = path + "/" + files[-1] + "/include/"
    arg = "-I" + path
    if canFindBuiltinHeaders(index, [arg]):
      return path
  except:
    pass

  knownPaths = [
    "/usr/lib/clang", # Gentoo
    "/usr/lib64/clang" # OpenSuse 64 bit
  ]

  for path in knownPaths:
    try:
      files = os.listdir(path)
      files = sorted(files)
      path = path + "/" + files[-1] + "/include/"
      arg = "-I" + path
      if canFindBuiltinHeaders(index, [arg]):
        return path
    except:
      pass

  return None

This function correct for gentoo 64bit and will be correct for openSuse 64bit.
Correct path for gentoo 64bit "/usr/lib/clang/3.2/include"

@tobiasgrosser
Copy link
Collaborator

Nice, can you open a pull request for this?

@Urich
Copy link
Author

Urich commented Jan 20, 2013

Yes.

@tobiasgrosser
Copy link
Collaborator

Btw, it seems @cartman's version is a little denser. Do you see any benefit in the dublicated code in your version?

@Urich
Copy link
Author

Urich commented Jan 20, 2013

Duplicate code is not very well. In function from @cartman need some fix. In the variable knownPaths must be added to " library_path + "/../clang" "
knownPaths = [library_path + "/../lib/clang", library_path + "/../lib64/clang" , library_path + "/../clang", "/usr/lib/llvm"]

@Urich
Copy link
Author

Urich commented Jan 20, 2013

I don't undestend, how this function be correct for openSuse. My value g:clang_library_path="/usr/lib/llvm" and "/usr/lib/clang/3.2/include".What a path libclang for the openSuse?

@ismail
Copy link

ismail commented Jan 20, 2013

@Urich Ah I missed that. If library_path is supposed to be path to path to libclang.so then the correct function would be like this:

For example for 32bit library_path would be

/usr/lib

and for 64bit

/usr/lib64

def getBuiltinHeaderPath(library_path):
  knownPaths = [library_path + "/clang", "/usr/lib/llvm"]
  for path in knownPaths:
      try:
          files = os.listdir(path)
          files = sorted(files)
          path = path + "/" + files[-1] + "/include/"
          arg = "-I" + path
          if canFindBuiltinHeaders(index, [arg]):
              return path
      except:
          pass

  return None

Anything I am missing here?

@Urich
Copy link
Author

Urich commented Jan 20, 2013

def getBuiltinHeaderPath(library_path):
  knownPaths = [
          library_path + "/../lib/clang",  # default value
          library_path + "/../clang"       # gentoo, opesuse
          ]
  for path in knownPaths:
      try:
          files = os.listdir(path)
          files = sorted(files)
          path = path + "/" + files[-1] + "/include/"
          arg = "-I" + path
          if canFindBuiltinHeaders(index, [arg]):
              return path
      except:
          pass

  return None

I think the function should be something like that.

@Urich
Copy link
Author

Urich commented Jan 20, 2013

If path library_path + "/clang" correct for opensuse then.

knownPaths = [
          library_path + "/../lib/clang",  # default value
          library_path + "/../clang"       # gentoo
          library_path + "/clang"          # opesuse
          ]

@ismail
Copy link

ismail commented Jan 20, 2013

This whole function is unnecessarily complex imho, running clang to ask for library_path would be easier but yes

library_path + "/clang" will work for openSUSE.

@tashia
Copy link

tashia commented Jan 26, 2013

HI, I tried to install the clang_complete on my machine(ubuntu 11.10), at the beginning I ran into the problem "libclang not found". I found that there was no libclang.so existing on my computer. so I just download the libclang.so, at the same time I installed llvm, then I put the libclang.so under the llvm folder. set g:clang_library_path='/usr/lib/llvm-2.9'. Then I ran into this "Libclang can not find the builtin includes" issue! Can anybody tell me what mistakes I made and what to do to fix it? I googled a lot can not find a solution. Thanks!

@xavierd
Copy link
Owner

xavierd commented Jan 29, 2013

@tashia, your problem is different. Please open a new bug, but I do remember that clang < 3.0 weren't supported anymore by clang_complete.

@tobiasgrosser
Copy link
Collaborator

Actually, @tashia seems to have the same problem. clang 2.9 should work.

@tashia, where did you download libclang.so? Did you download it by itself? Normally you should have downloaded an entire archive that also contains a copy of clang for example. In this archive there should be a library directory included that contains files like "stdint.h". Do you have such files?

@tobiasgrosser
Copy link
Collaborator

I created the following pull request: #265

Could you verify it works for OpenSuse and Gentoo?

@RudolfVonKrugstein
Copy link

Hey, I also get the message, that libclang can not find the builtin includes.
I installed clang from svn on a ubuntu system.
I added

let g:clang_user_options = "-I/usr/lib/clang/3.3/include"

which I hoped to be correct, because /usr/lib/clang/3.3/include containts lots of headers (stddef.h for example).
Is there something wrong on how I set the option?

Edit: Seems like I also need to set g:clang_library_path. Then it works.

@tobiasgrosser
Copy link
Collaborator

Rudolf, did you check if #265 fixes the problem without requiring g:clang_library_path to be set?

@RudolfVonKrugstein
Copy link

Hey,

If I use the add_builtin_directories branch from tobig/clang_complete, it works without setting g:clang_user_options or g:clang_library_path.

@Alexander-Shukaev
Copy link

I get the same warning. Windows machine here. Just upgraded - to the current commit. It seems you've deprecated getopts. So tell me how on earth libclang.dll is supposed to deduce built-in include paths of MinGW-w64 now? Additionally, if you've deprecated it, then probably you should remove {anything} suggestion in g:clang_auto_user_options help.

@tobiasgrosser
Copy link
Collaborator

I am not looking for anything from gcc. libclang.dll should come itself with a directory of builtin includes. How did you install libclang.dll? Did you compile it from source?

Can you look for a file called stddef.h in the llvm install directory:

$ find llvm/install/ -name stddef.h
llvm/install/lib/clang/3.3/include/stddef.h

This file comes with my LLVM installation. Do you have it? Where is it placed?

@tobiasgrosser
Copy link
Collaborator

Also, I am a little surpriced. Why is libclang.dll installed in a directory called 'bin'. I would have expected to find it
in a directory called 'lib*'

@Alexander-Shukaev
Copy link

Yes, I have compiled it from source. Indeed, on Windows it is located there, because .dll are a bit different from .so. Anyway, eveything is as you say: stddef.h is in D:\Toolchains\x64\LLVM\3.3\lib\clang\3.3\include.

$ clang -print-search-dirs
programs: =d:\Toolchains\x64\LLVM\3.3\bin:d:/Toolchains/x64/LLVM/3.3/bin
libraries: =d:/Toolchains/x64/LLVM/3.3/bin\..\lib\clang\3.3

@tobiasgrosser
Copy link
Collaborator

Can you try this branch:

https://github.com/tobig/clang_complete/tree/debug_builtins

and enable let g:clang_debug = 1

When starting vim (and typing :mess) you should see something like:

Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc
Search result: False
Searching path for builtin includes
Checking path: /home/grosser/Downloads/clang+llvm-3.2-x86_64-linux-ubuntu-12.04/lib/../lib/clang
['3.2', '3.1']
SubDir: 3.2
Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc -I/home/grosser/Downloads/clang+llvm-3.2-x86_64-
linux-ubuntu-12.04/lib/../lib/clang/3.2/include/
Search result: True

At least one of the clang commands should work. If non none references D:\Toolchains\x64\LLVM\3.3\lib\clang\3.3\include, then we need to figure out what is missing. I assume the directory separator is different in windows. Maybe you can figure out what exactly is wrong.

@Alexander-Shukaev
Copy link

Cool... What's going on? :)

Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc
Search result: False
Searching path for builtin includes
Checking path: /../lib/clang
Checking path: /../clang
Checking path: /clang
Checking path: /
['$$PendingFiles', '$RECYCLE.BIN', 'AppData', 'Applications', 'CommonFiles', 'Config.Msi', 'Distributio
ns', 'Documents and Settings', 'Drivers', 'Libraries', 'Progr
am Files', 'Program Files (x86)', 'ProgramData', 'ProgramFiles', 'ROMs', 'System Volume Information', '
Toolchains', 'Users', 'Utilities', 'VirtualStore']
SubDir: VirtualStore
Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc -I//VirtualStore/inc
lude/
Search result: False
Checking path: /usr/lib/clang
WARNING: libclang can not find the builtin includes.
         This will cause slow code completion.
         Please report the problem.

@Alexander-Shukaev
Copy link

My first guess would be as follows. It seems like clang_complete heavily relies on g:clang_library_path. For instance, I didn't set it because the directory containing libclang.dll is in the $PATH. Could this be the reason for not concatenating D:\Toolchains\x64\LLVM\3.3\bin with the first check /../lib/clang?

@tobiasgrosser
Copy link
Collaborator

Yes, that could be the reason. Can you set clang_library_path to D:\Toolchains\x64\LLVM\3.3\bin?

I currently don't have an idea how to get the library location automatically, in case it is already in the path. Is there a python function for this?

@Alexander-Shukaev
Copy link

So, bingo:

Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc
Search result: False
Searching path for builtin includes
Checking path: D:/Toolchains/x64/LLVM/3.3/bin/../lib/clang
['3.3']
SubDir: 3.3
Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc -ID:/Toolchains/x64/
LLVM/3.3/bin/../lib/clang/3.3/include/
Search result: True

@Alexander-Shukaev
Copy link

Can't you simply write something like os.path.abspath("libclang.dll")?

@Alexander-Shukaev
Copy link

Another way, probably more boilerplate, but works 100%, is to simply traverse all directories listed in $PATH environment variable and look for libclang.dll (or .so or whatever the extension is) there. As soon as you find one - you record this path as its root.

@tobiasgrosser
Copy link
Collaborator

On 02/20/2013 05:44 PM, Haroogan wrote:

Another way, probably more boilerplate, but works 100%, is to simply traverse all directories listed in $PATH environment variable and look for libclang.dll (or .so or whatever the extension is) there. As soon as you find one - you record this path as its root.

I pushed another change. Can you look if it find the library?

Tobi

@Alexander-Shukaev
Copy link

Well, I'd like to return to the issue since it is not resolved yet. Of course I don't get this warning anymore. However, std namespace will never be completed now for the obvious reason - clang does not come with it's own standard library on Windows (it is still in development). Therefore, my clang does not have includes for standard library.

That's why when I used getopts it automatically generated this neat file:

-Id:/Toolchains/x64/MinGW-w64/4.7.2/include/c++/4.7.2/
-Id:/Toolchains/x64/MinGW-w64/4.7.2/include/c++/4.7.2/x86_64-w64-mingw32/
-Id:/Toolchains/x64/MinGW-w64/4.7.2/include/c++/4.7.2/backward/
-Id:/Toolchains/x64/MinGW-w64/4.7.2/lib/gcc/x86_64-w64-mingw32/4.7.2/include/
-Id:/Toolchains/x64/MinGW-w64/4.7.2/lib/gcc/x86_64-w64-mingw32/4.7.2/include-fixed/
-Id:/Toolchains/x64/MinGW-w64/4.7.2/x86_64-w64-mingw32/include/

How is it supposed to work now?

@tobiasgrosser
Copy link
Collaborator

clang_complete does find the libraries using the normal clang driver. If clang++ and clang as compilers work correctly, clang_complete should also work. If clang++ and clang have issues finding such libraries, this is a clang bug that should be reported upstream. (You can also copy the old getopts scripts into clang_complete to work around this, but that would just be a workaround)

@Alexander-Shukaev
Copy link

The output now is:

Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc
Search result: False
Searching path for builtin includes
LIBRARY: D:\Toolchains\x64\LLVM\3.3\bin\libclang.dll
Checking path: /../lib/clang
Checking path: /../clang
Checking path: /clang
Checking path: /
['$$PendingFiles', '$RECYCLE.BIN', 'AppData', 'Applications', 'CommonFiles', 'Config.Msi', 'Distributio
ns', 'Documents and Settings', 'Drivers', 'Libraries', 'Progr
am Files', 'Program Files (x86)', 'ProgramData', 'ProgramFiles', 'System Volume Information', '
Toolchains', 'Users', 'Utilities', 'VirtualStore']
SubDir: VirtualStore
Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc -I//VirtualStore/inc
lude/
Search result: False
Checking path: /usr/lib/clang
WARNING: libclang can not find the builtin includes.
         This will cause slow code completion.
         Please report the problem.

Concerning the issue, do you have all std includes in clang distribution on linux? If yes, then you don't have problems with completing std, do you? What do you think can be done on Windows to alleviate this? I seems like getopts is the only way to go for now...

@tobiasgrosser
Copy link
Collaborator

On 02/20/2013 06:02 PM, Haroogan wrote:

The output now is:

Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc
Search result: False
Searching path for builtin includes
LIBRARY: D:\Toolchains\x64\LLVM\3.3\bin\libclang.dll
Checking path: /../lib/clang
Checking path: /../clang
Checking path: /clang
Checking path: /
['$$PendingFiles', '$RECYCLE.BIN', 'AppData', 'Applications', 'CommonFiles', 'Config.Msi', 'Distributio
ns', 'Documents and Settings', 'Drivers', 'Libraries', 'Progr
am Files', 'Program Files (x86)', 'ProgramData', 'ProgramFiles', 'System Volume Information', '
Toolchains', 'Users', 'Utilities', 'VirtualStore']
SubDir: VirtualStore
Checking for builtins with: echo '#include "stddef.h"' |  clang - -E -nobuiltininc -I//VirtualStore/inc
lude/
Search result: False
Checking path: /usr/lib/clang
WARNING: libclang can not find the builtin includes.
          This will cause slow code completion.
          Please report the problem.

Great. find_library works.

I will write a proper patch at some point, but for now you can probably
just set the library path.

Regarding the std includes. On linux and mac os x the clang driver finds
them automatically (both for clang_complete and for the clang binary).
The same should be true for windows. If the driver does not find them,
we should fix this upstream. I propose to report a bug to clang
including the paths where the std includes can be found by default on
windows.

Cheers,
Tobi

@Alexander-Shukaev
Copy link

For the record, I've just came across this page. Is that what you mean when referring to clang driver? Especially, this:

Clang expects the GCC executable “gcc.exe” compiled for i686-w64-mingw32 (or x86_64-w64-mingw32) to be present on PATH.

@tobiasgrosser
Copy link
Collaborator

On 02/20/2013 06:12 PM, Haroogan wrote:

For the record, I've just came across this page. Is that what you mean when referring to clang driver? Especially, this:

Clang expects the GCC executable “gcc.exe” compiled for i686-w64-mingw32 (or x86_64-w64-mingw32) to be present on PATH.

Yes, this page. But rather the information a little above. clang does
not yet have information for gcc 4.7.2. This patch may help:

diff --git a/clang/lib/Frontend/InitHeaderSearch.cpp
b/clang/lib/Frontend/InitHeaderSearch.cpp
index 35eec56..56f10fc 100644
--- a/clang/lib/Frontend/InitHeaderSearch.cpp
+++ b/clang/lib/Frontend/InitHeaderSearch.cpp
@@ -398,6 +398,7 @@ AddDefaultCPlusPlusIncludePaths(const llvm::Triple
&triple, const HeaderSearchOp
AddMinGW64CXXPaths(HSOpts.ResourceDir, "4.6.2");
AddMinGW64CXXPaths(HSOpts.ResourceDir, "4.6.3");
AddMinGW64CXXPaths(HSOpts.ResourceDir, "4.7.0");

  • AddMinGW64CXXPaths(HSOpts.ResourceDir, "4.7.2");
    // mingw.org C++ include paths
    AddMinGWCPlusPlusIncludePaths("/mingw/lib/gcc", "mingw32",
    "4.5.2"); //MSYS
    #if defined(_WIN32)

I think this is really a problem with the clang driver that should be
reported upstream.

Tobias

@egmkang
Copy link

egmkang commented Apr 27, 2013

please add "/usr/local/lib/clang" into the search path.

@tobiasgrosser
Copy link
Collaborator

On Sat, 2013-04-27 at 01:15 -0700, egmkang wrote:

please add "/usr/local/lib/clang" into the search path.


Reply to this email directly or view it on GitHub:
#238 (comment)

please add "/usr/local/lib/clang" into the search path.

Could you create a patch and send a pull request?

Tobi

@statquant
Copy link

I am using a vim 32 bit compiled by @Haroogan, I am still having the pb referenced here... I filled a post in SO http://stackoverflow.com/questions/18801354/clang-complete-failed-with-libclang-message?noredirect=1#comment27727088_18801354 is there a description how to fix the issue ?

@dnery
Copy link

dnery commented May 17, 2016

This problem popped up for me after updating clang to 3.8.0, the clang folder probably changed it's internal layout and messed up the script. I think I solved the problem on my end...

The bug in the script is when defining subDir. You see, retrieving from files[-1] will render, in my case, an executable (ccc-analyzer, specifically), because sorted will put the directory I want in the first position, not the last (sorted won't even change files array, actually). I ran an interactive test:

revenant% python2
Python 2.7.11 (default, Mar 31 2016, 06:18:34) 
[GCC 5.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> path = "/../lib/clang" # library_path is initially empty, so it's safe to assume this will be first value...
>>> import os
>>> files = os.listdir(path)
>>> print files
['3.8.0', 'c++-analyzer', 'ccc-analyzer']
>>> files = sorted(files) # Needed, but changes nothing here. '3.8.0' is the dir I want...
>>> print files
['3.8.0', 'c++-analyzer', 'ccc-analyzer']
>>> wrongSubDir = files[-1] # What I'm getting...
>>> wrongSubDir
'ccc-analyzer'
>>> correctSubDir = files[0] # What I want...
>>> correctSubDir
'3.8.0'
>>> quit()

So, effectively, all I had to do was change the -1 index to 0 when retrieving from files array. The function, now, becomes this:

def getBuiltinHeaderPath(library_path):
  if os.path.isfile(library_path):
    library_path = os.path.dirname(library_path)

  knownPaths = [
          library_path + "/../lib/clang",  # default value
          library_path + "/../clang",      # gentoo
          library_path + "/clang",         # opensuse
          library_path + "/",              # Google
          "/usr/lib64/clang",              # x86_64 (openSUSE, Fedora)
          "/usr/lib/clang"
  ]

  for path in knownPaths:
    try:
      files = os.listdir(path)
      if len(files) >= 1:
        files = sorted(files)
        subDir = files[0]
      else:
        subDir = '.'
      path = path + "/" + subDir + "/include/"
      arg = "-I" + path
      if canFindBuiltinHeaders(index, [arg]):
        return path
    except:
      pass

  return None

I can't assume that the internal layout of the clang folder is, now, the same for everyone, but this did the trick for me. If this is, in fact, a solution, then I suggest a contributor updates it (I don't think a pull request is necessary).

Anyways, this is what it took me, so makes sense to let everyone else know... I've just that feeling that a lot are having the same problem I was am.

@couragelfyang
Copy link

@ dnery
I came across this issue too, your solution works.

@dnery
Copy link

dnery commented May 23, 2016

@AriaAsuka I made a pull-request with an equivalent solution. In my previous proposal I'm considering that there are no other subdirectories named after a version of clang; I noticed that simply reversing the ordering of the files array before defining subDir is a more robust solution. The aforementioned fix is #490, maybe this issue can finally be closed.

@deffi420
Copy link
Contributor

@dnery I think your fix is wrong (see my comments in your PR #490).

My fix: PR #491

@dnery
Copy link

dnery commented May 24, 2016

@deffi420 it is, indeed. #491 patches this issue properly.

@xaizek xaizek closed this as completed in 3c1a6ff May 25, 2016
@tibco-ranjan
Copy link

I solve this issue by following below steps. (CentOS -7)

  1. Install clang-complete from rip-rip.
    https://github.com/Rip-Rip/clang_complete

  2. Done following entries in ~/.vimrc
    " path to directory where library can be found
    let g:clang_library_path='/usr/lib/clang-private/'
    let g:clang_user_options='|| exit 0'
    let g:clang_complete_auto = 1
    let g:clang_complete_copen = 1
    let g:clang_debug = 1

  3. After installation, I got the clang-complete library in the folder "/usr/lib/clang-private/"
    root@localhost:~/.vim/plugin# ls -lrt /usr/lib/clang-private/
    total 34336
    -rwxr-xr-x. 1 root root 2846788 Apr 11 2018 libclangStaticAnalyzerCheckers.so.5.0.0
    -rwxr-xr-x. 1 root root 930224 Apr 11 2018 libclangParse.so.5.0.0
    -rwxr-xr-x. 1 root root 621252 Apr 11 2018 libclangToolingRefactor.so.5.0.0
    -rwxr-xr-x. 1 root root 69024 Apr 11 2018 libclangToolingCore.so.5.0.0
    -rwxr-xr-x. 1 root root 1334448 Apr 11 2018 libclangStaticAnalyzerCore.so.5.0.0
    -rwxr-xr-x. 1 root root 530736 Apr 11 2018 libclang.so.5.0
    -rwxr-xr-x. 1 root root 1675192 Apr 11 2018 libclangSerialization.so.5.0.0
    -rwxr-xr-x. 1 root root 7506328 Apr 11 2018 libclangSema.so.5.0.0
    -rwxr-xr-x. 1 root root 64508 Apr 11 2018 libclangRewrite.so.5.0.0
    -rwxr-xr-x. 1 root root 305496 Apr 11 2018 libclangIndex.so.5.0.0
    -rwxr-xr-x. 1 root root 22896 Apr 11 2018 libclangFrontendTool.so.5.0.0
    -rwxr-xr-x. 1 root root 65064 Apr 11 2018 libclangEdit.so.5.0.0
    -rwxr-xr-x. 1 root root 2194228 Apr 11 2018 libclangARCMigrate.so.5.0.0
    -rwxr-xr-x. 1 root root 214440 Apr 11 2018 libclangStaticAnalyzerFrontend.so.5.0.0
    -rwxr-xr-x. 1 root root 490744 Apr 11 2018 libclangRewriteFrontend.so.5.0.0
    -rwxr-xr-x. 1 root root 752560 Apr 11 2018 libclangLex.so.5.0.0
    -rwxr-xr-x. 1 root root 1227244 Apr 11 2018 libclangFrontend.so.5.0.0
    -rwxr-xr-x. 1 root root 1436748 Apr 11 2018 libclangDynamicASTMatchers.so.5.0.0
    -rwxr-xr-x. 1 root root 1405400 Apr 11 2018 libclangDriver.so.5.0.0
    -rwxr-xr-x. 1 root root 4083752 Apr 11 2018 libclangCodeGen.so.5.0.0
    -rwxr-xr-x. 1 root root 2001524 Apr 11 2018 libclangBasic.so.5.0.0
    -rwxr-xr-x. 1 root root 3416144 Apr 11 2018 libclangAST.so.5.0.0
    -rwxr-xr-x. 1 root root 343120 Apr 11 2018 libclangTooling.so.5.0.0
    -rwxr-xr-x. 1 root root 505440 Apr 11 2018 libclangFormat.so.5.0.0
    -rwxr-xr-x. 1 root root 440388 Apr 11 2018 libclangASTMatchers.so.5.0.0
    -rwxr-xr-x. 1 root root 629208 Apr 11 2018 libclangAnalysis.so.5.0.0

  4. I didn't getany llvm library, as I had no clang installed on my system.

  5. Installed clang
    yum install -y clang.

  6. Added the llvm and clang-private lib path in the "libclang.py" script as shown below.

root@localhost:~/.vim/plugin# ls
clang clang_complete.vim kinds.py kinds.pyc libclang.py snippets

knownPaths = [
library_path + "/../lib/clang", # default value
library_path + "/../clang", # gentoo
library_path + "/clang", # opensuse
library_path + "/", # Google
"/usr/lib64/clang", # x86_64 (openSUSE, Fedora)
"/usr/lib/clang" ,
"/usr/lib/clang-private" ,
"/usr/lib/llvm"
]

  1. Open any cpp file, the warning message didn't appread
    "WARNING: libclang can not find the builtin includes." [GONE ha ha ha.............]

#include
#include

using namespace std;

int main()
{
std::vector vec;
vec.
at f std::vector<int, std::allocator >::reference at(std::vector::size_type __n)
} reserve f void reserve(std::vector::size_type __n)
~ erase f std::vector<int, std::allocator >::iterator erase(std::vector<int, std::allocator >::iter
~ erase f std::vector<int, std::allocator >::iterator erase(std::vector<int, std::allocator >::iter
~ operator[] f std::vector<int, std::allocator >::reference operator[](std::vector::size_type __n)
~ insert f std::vector<int, std::allocator >::iterator insert(std::vector<int, std::allocator >::ite
~ insert f void insert(std::vector<int, std::allocator >::iterator __position, std::vector::size_type __n
~ pop_back f void pop_back()
~ push_back f void push_back(const std::vector<int, std::allocator >::value_type &x)
~ data f std::vector<int, std::allocator >::pointer data()
~ back f std::vector<int, std::allocator >::reference back()
~ front f std::vector<int, std::allocator >::reference front()
~ operator= f std::vector<int, std::allocator > & operator=(const std::vector<int, std::allocator > &

~ ~vector ~ void ~vector()
~ swap f void swap(std::vector<int, std::allocator > &__x)
~ _M_fill_initialize f void _M_fill_initialize(std::vector::size_type __n, const std::vector<int, std::allocator >::v
~ clear f void clear()


Hope this will help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests