Using clang::tooling::RefactoringTool on cross-compiled code with different /usr/include

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Using clang::tooling::RefactoringTool on cross-compiled code with different /usr/include

Louis Dionne via cfe-dev
Hello everyone!
 
I am writing a tool using clang's  tooling::RefactoringTool  and want to apply it to ARM targeted sources. Those rely on their own sysroot to compile, which is incomplete and basically contains only lib and usr directories with proprietary stuff. Its /usr/include headers also differ from my system ones - so when parsing my sources with clang tool I get a lot of parsing errors related to header ordering, etc. And of course, with vendor-provided gcc4.8 everything is fine, which led me to a conclusion there's something wrong with how I use clang.
 
I've tried to surpass the problem by copying my /lib/clang/5.0.1/include to this sysroot (so clang builtin headers would work correctly with new include & lib) and changing my compile_commands.json to use -nostdinc++ -isystem /arm-hisiv300-linux/target/usr/include -isystem /arm-hisiv300-linux/gcc/include - so clang wouldn't rely on system headers.
 
Unforntunately it doesn't fool clang - it still tries to search for some headers in my host system:
 
arm-hisiv300-linux/bin/my-tool src/grabcommon/rtp_assemblers.cpp
In file included from src/grabcommon/rtp_assemblers.cpp:1:
...
In file included from /arm-hisiv300-linux/target/usr/include/limits.h:125: <- here #include_next is used to access compiler-specific <limits.h>
In file included from /arm-hisiv300-linux/bin/../lib/clang/5.0.1/include/limits.h:37: <- here clang #include_next <limits.h>
>>> /usr/include/limits.h:145:5 <<< error: function-like macro '__GLIBC_USE' is not defined <- here I'd expect /arm-hisiv300-linux/target/usr/include/limits.h, but get system one
#if __GLIBC_USE (IEC_60559_BFP_EXT)
 
I believe I have to pass "sysroot" directory as an argument to my tool and somehow construct RefactoringTool / CompilationDatabase instance so it take advantage of needed include directory, but how? Or am I entirely wrong and this calls for drastic measures like recompiling clang/LLVM for my needs? I am aware that I can mount --bind my/usr/include /usr/include (it works!), or put everything to some arm-based distro and use qemu, so instead of cross-compiling I just compile in place. However my intention is that the tool could be used as simple as my-tool --sysroot /dir file.cpp .

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev