To get started with libclang, I build a very simple program that tries to load a very simple source file. It fails with 'stddef.h' file not found.
Here is the program using libclang:
#include <clang-c/Index.h>
int main() {
CXIndex index = clang_createIndex(1,1);
const char *source_path = "foo.cpp";
clang_createTranslationUnitFromSourceFile(index,"foo.cpp",0,0,0,0);
}
(For conciseness, I left out code that is irrelevant to reproducing the issue).
And here is the file I am trying to load, foo.cpp:
#include <stddef.h>
int main() {}
I am using LLVM and Clang 6.0.1, compiled from source as follows:
cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local -DCMAKE_PREFIX_PATH=$HOME/local -DCMAKE_BUILD_TYPE=Release
make
make install
A quick search yields this promising post: Clang Error - stddef file not found? Unfortunately, this is about llvm 3.5, and I am using llvm 6.0.1. Also, the directory $HOME/local where I installed LLVM and Clang does not have a /usr/lib directory, so the solution proposed there does not work here.
The stddef.h header is present at $HOME/lib/clang/6.0.1/include/stddef.h. Explicitly adding this path as a -isystem option to the clang_createTranslationUnitFromSourceFile call solves the problem.
Moreover, the include search path used by clang_createTranslationUnitFromSourceFile is not the same as that used by clang++; clang++ foo.cpp works without errors.
Is there any documentation on the include search path used by clang_createTranslationUnitFromSourceFile and similar functions in libclang, so that I can determine which include paths need to be added?
Any other suggestions on how to invoke clang_createTranslationUnitFromSourceFile with a correct include search path, equivalent to the path used by clang++?
libclang works as if you tried to compile the file, i.e.: to parse a file it needs to know where to look for the headers, and potentially other info such as macro definitions, compile flags, etc.
clang_createTranslationUnitFromSourceFile has two parameters: num_clang_command_line_args and clang_command_line_args. There you need to pass actual header search path, e.g.:
const char *cli_args[] = { "-I", "~/local" };
clang_createTranslationUnitFromSourceFile(index, "foo.cpp", 2, cli_args, 0, 0);
Related
I try to get tests generated by the cxxtest framework working under a MinGW environment managed by mysys2. The tool generates C++ files with absolute paths. However, gcc seems to be unable to resolve this absolute paths.
Here is a minimal example to demonstrate the problem:
// file1.h
#include <iostream>
inline void hallo() { std::cout << "Hallo\n"; }
// main.cpp
#include "/home/phil/example/file1.h"
int main()
{
hallo();
return 0;
}
The file exists (at least the msys2 shell resolves the path):
$ ls /home/phil/example/file1.h
/home/phil/example/file1.h
... but calling g++ results in this error:
$ g++ main.cpp
main.cpp:1:38: fatal error: /home/phil/example/file1.h: No such file or directory
#include "/home/phil/example/file1.h"
^
compilation terminated.
Same error with clang.
Under a full Linux environment, the example works. It also works if I replace the absolute path by a relative one (#include "file1.h").
So, I assume the problem lies in the layer over Windows that is responsible to resolve paths. Not sure whether I should report it as a bug to the msys2 project, or whether it is a known problem. If it is a known problem, are there any workarounds (like setting -I options)?
(If possible, I would like to avoid replace the absolute paths, as they are in generated code by the cxxtest framework. Technically, running a postprocessing step on the generated files would be possible but seems like a hack in the long run.)
Since you are running compilers that use MinGW-w64 as their runtime environment, they don't recognize POSIX-style paths like that. I think they actually interpret the root directory "/" to be "C:\". Other than that, they would only recognize native Windows-style paths.
I recommend that you pass the argument -I/home/phil/example to your compiler from some program running in the msys-2.0.dll POSIX emulation runtime environment (e.g. /usr/bin/bash or /usr/bin/make). The msys-2.0.dll runtime will then convert that argument to use a native Windows path so the compiler can understand it, and statements like #include <file1.h> will work. Alternatively, you might try putting a Windows-style path in your source code, e.g. the path should start with C:\.
Note however that having absolute paths in source code or build scripts is a bad idea since it makes it harder to build the code on a different computer. You could consider using environment variables or relative paths.
Try using the MinGW compiler that Cygwin provides as a package. (In other words, forget the MSYS environment; work under Cygwin, but build the code as before, in the MinGW style.)
Then you should be able to have include references /home/phil; it will just resolve to C:\Cygwin\home\phil or wherever your Cygwin root is.
Actually, it might be possible under MSYS also (which, after all, is just the descendant of an old for of Cygwin). You just have to figure out what /home/phil is referring to, create that tree and work under there.
I am trying to make a directory using Boost.Filesystem (the directory can be provided by the user, so it may be a path with nested directories; all, some, or none of the directories in that path may exist to start). When I run the program, a directory is created, but it is not what I asked for; the string containing the path appears to be getting mangled. I never get the same result twice, but the name of the directory always starts with a colon.
A minimal example:
#include <iostream>
#include <boost/filesystem.hpp>
namespace fs = boost::filesystem;
int main(int argc, char* argv[]) {
fs::path path = "junk/morejunk";
if (!fs::create_directories(path)) {
std::cerr << "Failed to create directory " << path << ".\n";
}
return(0);
}
Running that, I get directories such as :#K%C5?, :%C0)%E0?, and :%C0%E9%93?.
I had some trouble getting Boost to link correctly, but the above program compiles and runs now. In case it's necessary, some information:
-- I'm using a Mac (OSX 10.9.4)
-- GCC and Boost both installed with MacPorts (Boost with the +gcc49 option)
-- GCC version 4.9.2_1
-- Boost version 1.57.0_1
-- my Makefile looks like
CC = /opt/local/bin/g++
FLAGS = -I/opt/local/include -L/opt/local/lib -lboost_system-mt -lboost_filesystem-mt
driver : driver.cpp
$(CC) $(FLAGS) -o driver driver.cpp
Any suggestions welcome; it's been a while since I've used C++ much, and I'm not very experienced with Boost.
Out on a limb, make sure you save your file as ASCII, latin1 or UTF8.
Otherwise you might have undefined behaviour from incompatible library versions.
You could use DYLD_LIBRARY_PATH to get the preferred libraries for boost (the ones which you link against). See also Is it OK to use DYLD_LIBRARY_PATH on Mac OS X? And, what's the dynamic library search algorithm with it?
I had the same problem of mangled directory names. I installed boost using brew install boost and gcc using brew install gcc6.
It turns out that the boost was build with the Apple's version of the GCC compiler, and the source file with the original GCC compiler. When I build your source file with Apple's compiler it does work.
Alternatively, build boost yourself with your compiler of choice.
See also the answer on a related question, https://stackoverflow.com/a/4798180/2535529.
I want to use Clang and LibTooling to create some C++ source analysis and transformation tools. I've built Clang and LibTooling following this tutorial, and I've been able to run and create some analysis tools and compile C++ programs using the Clang binary I built. However, if I include headers from the standard library (in either source files or my tools), I run into issues when compiling or running the source files/tools. For instance, if I run clang-check on the following C++ source file:
#include <iostream>
int main() {
std::cout << "Hello";
return 0;
}
I get "fatal error: 'iostream' file not found". (Note: I can compile C++ programs, e.g. ones with user-defined classes, just not C++ programs using the standard library.) In an attempt to resolve the issue, I built libc++ (following this guide, building it in the llvm/project directory where I built LLVM and Clang), but I'm still having trouble getting Clang and the tools to use libc++. Now, if I try to compile a test file using:
export CPLUS_INCLUDE_PATH="~/clang-llvm/llvm/projects/libcxx/include"
export LD_LIBRARY_PATH="~/clang-llvm/llvm/projects/libcxx/lib"
~/clang-llvm/llvm/build/bin/clang++ ~/Documents/main.cpp
Then I get "fatal error: 'unistd.h' file not found". So my question is this: how do I properly point Clang and my tools to use libc++?
I am running OS X Yosemite 10.10 and using Clang 3.6.0.
Clang comes with some custom includes. So usually you have clang in
/usr/bin/clang++
and the includes in
/usr/lib/clang/3.6.1/include
but clang looks for them as a relative path:
../lib/clang/3.6.1/include
so make sure this relative path is accessible from either the clang++ binary, or your libtooling application.
Include your tool into this:
#include "clang/Tooling/CommonOptionsParser.h" // For reading compiler switches from the command line
#include "clang/Tooling/Tooling.h"
static cl::OptionCategory MyToolCategory("SearchGlobalSymbols");
static cl::extrahelp MoreHelp("\nMore help text..."); // Text that will be appended to the help text. You can leave out this line.
/* Your code (definition of your custom RecursiveASTVisitor and ASTConsumer) */
/* Define class MyASTFrontendAction here, derived from ASTFrontendAction */
int main(int argc, const char **argv)
{
/* Your code */
CommonOptionsParser op(argc, argv, MyToolCategory); // Parse the command-line arguments
ClangTool Tool(op.getCompilations(), op.getSourcePathList()); // Create a new Clang Tool instance (a LibTooling environment)
return Tool.run(newFrontendActionFactory<MyASTFrontendAction>().get()); // Run custom Frontendaction
}
The CommonOptionsParser allows you to read commands from the command line that are passed to the compiler.
For example, you can now call your tool like this:
your-tool yoursourcefile.c -- -nostdinc -I"path/to/your/standardlibrary"
Everything after the double dash will be passed to the compiler. Possible flags are described here:
http://clang.llvm.org/docs/CommandGuide/clang.html
-nostdinc tells the Preprocessor not to look for standard include paths. You can specify you own paths instead after -I.
Hope it helped someone :) Ask me if I wasn't specific enough.
Did you move/rename any of the parent directories after building/installing? The compiler should have been configured to know where to look for its standard libraries without having to specify the environment variable paths.
Use homebrew and install llvm using the command
brew install llvm
Your problem should be solved.
I have downloaded the mimetic library installation files,
and followed the INSTALL instructions.
./configure
a script that creates the make file after checking a series of things.
make
compiles the cpp files, after this different .o and .lo files appear in the original folder.
make install
seems to do a lot but the only thing that I seem to notice is that a mimetic directory
appears under /usr/local/include with all the header files.
than I try to compile the most simple main file possible:
(as offered in the library site : original example )
#include <mimetic/mimetic.h>
using namespace mimetic;
int main()
{
MimeEntity me;
return 0;
}
I am compiling with following command ( on CentOS 5.7, gcc version : 4.1.2 ):
g++ mimetic.cpp
The error I get:
/tmp/ccWnsteO.o: In function `main':
mimetic.cpp:(.text+0x80): undefined reference to `mimetic::MimeEntity::MimeEntity()'
mimetic.cpp:(.text+0x91): undefined reference to `mimetic::MimeEntity::~MimeEntity()'
collect2: ld returned 1 exit status
From this I understand that the header files are found but the source/library itself
is missing.
the MimeEntity constructor declaration appears in : /usr/local/include/mimetic/mimeentity.h
when I do a search for mimeentity I get the following :
/home/mimetic-0.9.7/mimetic/mimeentity.o
/home/mimetic-0.9.7/mimetic/mimeentity.h
/home/mimetic-0.9.7/mimetic/mimeentitylist.h
/home/mimetic-0.9.7/mimetic/mimeentity.cxx
/home/mimetic-0.9.7/mimetic/.libs/mimeentity.o
/home/mimetic-0.9.7/mimetic/mimeentity.lo
/home/mimetic-0.9.7/mimetic/.deps/mimeentity.Plo
/usr/local/include/mimetic/mimeentity.h
/usr/local/include/mimetic/mimeentitylist.h
I've tried with a search path to the libraries but the same error appears
g++ mimetic.cpp -L/home/mimetic-0.9.7/mimetic/
Something else strange is happening, when I try to compile the main mimetic.cpp file
with the line
MimeEntity me;
changed to
MimeEntity me();
it compiles.
You are getting a linker error simply because you are not referencing the library when compiling the test source file. It needs to be something like:
g++ mimetic.cpp -l<libraryname>
The reason it compiles when you add the braces is that you are really declaring a function called 'me' that returns a MimeEntry. While it compiles, it does not do what you want.
The command you are using to build your mimetic example seems incomplete. You are specifying library search patch (-L) but not the library itself.
Make sure that -L option specified the location of the mimetic library
Add -l'the-name-of-the-mimetic-library'. My guess would be -lmimetic
Add -I (that is capital i) option for the location of the headers.
I have the following very simple application that compiles and runs fine:
EDIT: changed the example to be simpilar to end confusion of the real issue
int main() {
return 0;
}
As soon as I add #include <string> (and not even reference std::string), it fails to compile and I get the following error:
/usr/include/c++/4.1.2/bits/allocator.h:82 error: expected template-name before '<' token
Along with about 456 other, similar errors.
Any ideas? Thanks!
UPDATE:
Line 82 of /usr/include/c++/4.1.2/bits/allocator.h references the template __glibcxx_base_allocator at the location of the error. That template is defined in bits/c++allocator.h. When I search the system for that file, I get 3 hits, but none of them are in /usr/include/c++/4.1.2/bits/ as one would expect.
I have version 3.1.6, 4.1.1, and 4.3.2, but not 4.1.2 as the rest of the includes I am using. I am not sure which one is being used (if any, however, I don't get any error for an unknown file), but it seems the problem may stem from this.
The problem appears to be the installed development packages are not correct or incomplete (not to be confused with corrupt). Forcing g++ to use different include versions corrects that:
g++ -nostdic++ hello.cc -o hello -I/usr/include/c++/3.4.6
All the alternative directories (4.1.1, 4.1.2 and 4.3.2) are incomplete causing inappropriate files to be included causing the unusually errors. For example:
/usr/include/c++/4.1.2/bits/allocator.h requires __glibcxx_base_allocator located in bits/c++allocator.h which is being included from either /usr/include/c++/4.1.1 or /usr/include/c++/4.3.2 and appear to be incompatible. Forcing the compiler to use the only complete set of includes rectifies this.
Almost certainly g++ is detecting .cc as a C source file, not C++ and passes it through to gcc instead of compiling as C++. You can easily test by renaming your file to hello.C. There's also a language parameter to g++ you can use.
EDIT: This seems to work fine in g++ 4.2 with a .cc extension so that might not be it. Do you have any other headers included you aren't showing us? They could be interfering with <string>.
EDIT2: Alternatively your headers might not be set up right. Does this work:
#include <string>
int main()
{
return 0;
}
Errors like this have been heard of to occur when the C++ standard library headers are corrupted/not fully installed – maybe there is even a message referring to a missing include among your 456 other errors.
In any case, make sure that libstdc++-devel, resp. the package containing the C++ standard library header files of your distribution, is properly installed.
Check your include path. The paths can be specified as environment variables or specified on the command line. You could be using an include file from a different compiler or different version of the same compiler.
Also, try using <cstdio> rather than <stdio.h>.
Another suggestion: change <> to "".
This could be error caused at preprocess stage. Just preprocess your cpp file by passing flag -E to gcc and Look at the place the compiler complains.