[cfe-dev] Paths to system header files

[Mikhail Ramalho via cfe-dev]

Hi,

Right now, I don't understand why I need to convert the builtin headers to
> strings, but of course I would like to have a look to the script. Any help
> is very welcomed. You can send it directly to me email if you prefer.
>
> By converting them to strings, you can produce a binary that doesn't care
about the location of the builtin headers. Static linked binaries will
specially benefit from this, as you won't need to ship the builtin headers
with your program.


> - "esbmc_intrinsics.h" is always that string? is that a real file?
>
Same as the builtin headers, it's a virtual file "represented" by a string.

> - What are "path", "instrinsics" and "compiler_string" in your code?
>
So, 'path' is the absolute path to the program under verification (I'm
developing a bounded model checker), 'instrinsics' is the content of the
virtual file 'esbmc_intrinsics.h' and 'compiler_string' is a vector that
contains the arguments given to clang (e.g., -funsigned-char, defines, etc.)


> Could you tell me then how to obtain clang 3.8?
>
You can build llvm+clang 3.8: http://llvm.org/docs/GettingStarted.html

If you use Fedora 24, it has the dynamic libraries available for download
(not sure why static ones are not available anymore, though).

Cheers,

Thanks again.
>
>
> *El día 26 feb 2016 14:06, Pedro Delgado Perez
> <pedro.delgadoperez at mail.uca.es <pedro.delgadoperez at mail.uca.es>> escribió:*
>
> Sorry about the format of the previous message. I write it again here.
>
> Sorry, Jacob, no idea on how to use your solution in my code. Manuel,
> nothing is written in your message I think...
> My code is something like this:
>
> static cl::OptionCategory MyToolCategory("My tool options");
>
>  int main(int argc, const char **argv) {
>    CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
>    ClangTool Tool(OptionsParser.getCompilations(),
>    OptionsParser.getSourcePathList());
>    return Tool.run(newFrontendActionFactory<SyntaxOnlyAction>().get());
> }
>
> What I was doing by the moment is to process argv before creating the
> object OptionsParser and then include internal Clang headers, but I guess I
> can't do that when using Json compilation database. Could you help me with
> that? Otherwise, is there a way to ship in the executable all the necessary
> headers so that the user does not require to have clang installed?
>
> Thanks.
>
>
> *El día 26 feb 2016 14:03, Pedro Delgado Perez
> <pedro.delgadoperez at mail.uca.es <pedro.delgadoperez at mail.uca.es>> escribió:*
>
> Sorry, Jacob, no idea on how to use your solution in my code. Manuel,
> nothing is written in your message I think...
>
> My code is something like this:
>
> static cl::OptionCategory MyToolCategory("My tool options");
>
>  int main(int argc, const char **argv) {
>    CommonOptionsParser <http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1CommonOptionsParser.html> OptionsParser(argc, argv, MyToolCategory);   ClangTool <http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1ClangTool.html> Tool(OptionsParser.getCompilations(),                  OptionsParser.getSourcePathList());   return Tool.run <http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1ClangTool.html#acec91f63b45ac7ee2d6c94cb9c10dab3>(newFrontendActionFactory<SyntaxOnlyAction>().get()); }
>
> What I was doing by the moment is to process argv before creating the
> object OptionsParser and then include internal Clang headers, but I guess I
> can't do that when using Json compilation database. Could you help me with
> that? Otherwise, is there a way to ship in the executable all the necessary
> headers so that the user does not require to have clang installed?
>
> Thanks.
>
>
> *El día 26 feb 2016 10:37, Pedro Delgado Perez
> <pedro.delgadoperez at mail.uca.es <pedro.delgadoperez at mail.uca.es>> escribió:*
>
> Hello,
>
> Perhaps this question has been asked before, but I couldn't find a proper
> solution for this issue. When I produce an executable and use it in another
> machine, sometimes Clang is not able to find system header files (for
> instance "limits.h") because the paths to find these headers are relative
> to the location of the Clang libraries.
>
> All the same, when I'm using FIXED COMPILATION, I'm able to automatically
> retrieve the paths to system headers of the machine where the executable is
> being run. I mean, I retrieve the paths and add them after "--" to the
> command through the option -isystem. However, when I'm using JSON
> COMPILATION DATABASE, I can't do that, so in this case I don't know how to
> solve this issue.
>
> What is the appropriate manner to handle this matter of the paths to
> system header files?
>
> Thanks.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>


-- 

Mikhail Ramalho.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160226/1631785c/attachment.html>