I'm working on creating a custom clang-tidy checker for a large codebase. To run my clang-tidy checker, I need to generate a compile_commands.json database for all files. The problem I'm facing is that this is a multi architecture project, so most of the files are compiled with two architecture flags, in this case, as extracted from compile_commands.json
-arch x86_64 -arch arm64
Unfortunately I don't think clang-tidy is capable of operating with multiple architectures because I get this error at every file checked:
13:40:08 [0;1;31merror: [0m[1munable to handle compilation,
expected exactly one compiler job in '
I found a similar issue resolved for clangd (https://github.com/llvm/llvm-project/commit/3bf77980d934c4aa383e4ea9a9a5de86598bea9b), but I couldn't find how I can bypass this issue except for modifying the codebase, which I do not want.
Related
Several static analysis tools designed for C/C++ exist, but they are not particularly useful for testing CUDA sources.
Since clang version 6 is able to compile CUDA, I wanted to check what are my options with using clang-tidy, which does not seem to have option for switching architectures.
Is there a way to make it work? For example compile time switch for turning on CUDA parser, extension in form of custom check, or is it maybe planned feature?
One of the problem with the clang-based tools is that they are not parsing the files in exactly the same way as clang does.
The first problem is that unlike C/C++ compilation, CUDA compilation compiles the source multiple times. By default clang creates multiple compilation jobs when you give it a CUDA file and that trips many tools that expect only one compilation. In order to work that around you need to pass --cuda-host-only option to clang-tidy.
You may also need to pass --cuda-path=/path/to/your/CUDA/install/root so clang can find CUDA headers.
Another problem you may run into would be related to include paths. Clang-derived tools do not have the same default include paths that clang itself uses and that occasionally causes weird problems. At the very least clang-tidy needs to find __clang_cuda_runtime_wrapper.h which is installed along with clang. If you run clang-tidy your-file.c -- -v it will print clang's arguments and include search paths it uses. Compare that to what clang -x c /dev/null -fsyntax-only -vprints. You may need to give clang-tidy extra include paths to match those used by clang itself. Note that you should not explicitly add the path to the CUDA includes here. It will be added in the right place automatically by --cuda-path=....
Once you have it all in place, clang-tidy should work on CUDA files.
Something like this:
clang-tidy your-file.cu -- --cuda-host-only --cuda-path=... -isystem /clang/includes -isystem /extra/system/includes
I am updating some old C++ projects to build on a 64-bit Linux machine for the first time, and I don't have much Linux experience. I need to build everything as 32-bit binaries, so I'm building everything with -m32 in the compiler and linker flags. I'm finding that, when linking to their dependencies, some must link with i386 shared objects, and some must link with x86_64 shared objects. If I only include the wrong folder in the linking path (-L/path/to/wrong/folder), it says
/usr/bin/ld: skipping incompatible xxx.so when searching for -lxxx
which I've come to understand means the architecture doesn't match what I'm trying to build.
The makefiles are nearly identical for two such differing projects, so it doesn't seem like I'm doing something obviously wrong there, and -m32 appears in the calls to gcc and g++ in the terminal. What could be causing this difference? Should I be concerned, or is it typical for this to happen?
Let me know if more information is needed to answer; I'm not really sure, due to inexperience with Linux and gcc, so apologies in advance.
Thanks #Wyzard and #duskwuff for the tips. I was indeed able to find my problem by using file on my .o files. It was just a silly mistake; I had inadvertently reverted the changes I made to one of the projects' make files, which included adding the -m32 flag. I think I misunderstood what the "x86_64" libraries are for, and that confused me (I had assumed it meant "32-bit process for 64-bit machine").
I have my pass that I tested on toy programs and now I want to run it on large programs, many of which are open source programs like memcached. Such programs have their own Makefile and a complicated compilation procedure. I want to generate a bitcode file for such programs to let my pass work on them. Help and suggestions will be appreciated!
Depending on what you're pass is doing you can:
Build with LTO: adding -flto to the CFLAGS and building your application with your own built linker plugin is quite seamless from a build system point of view. However it requires some understand about how to setup LTO.
Build with your own built clang: adding statically your pass to the LLVM pipeline and use your own built clang. Depending on the build system, exporting CC/CXX environment variable pointing to your installed clang should be enough.
Build by loading your pass dynamically into clang, for example this is what Polly is (optionally) doing.
If you add -emit-llvm to your clang flags, it will emit BC files instead of object files or LL files instead of assembly.
You'll likely have to modify the makefile some more bit that should get you started in the right direction.
I've bumped into the following annoying issue. I installed g++ via macports on OSX, everything works fine. However, cmake still detects clang++ as the cpp compiler. Therefore, I end up putting
export CXX=/opt/local/bin/g++
in my profile. Now, cmake correctly detects g++ as the compiler. The problem is that all the system headers that I include with
INCLUDE_DIRECTORIES(SYSTEM "/path/to/system/header)
are included as regular headers. In other words, I am getting a whole bunch of warnings (-Wall) which I'd very much like to suppress, since I don't care about warnings in system headers like Boost or Eigen.
Any idea how to address this issue? It's driving me crazy, and I am completely puzzled why adding CXX in the profile results in this behaviour. If I remove the export CXX from my profile and manually set CMAKE_CXX_COMPILER to g++ in the CMakeLists.txt then everything is fine, no more warnings for system files.
I finally figured out a solution, from a somehow randomly found post: http://www.cmake.org/pipermail/cmake/2011-June/044769.html. For some reason, the SYSTEM directive was ignored. Setting
SET(CMAKE_INCLUDE_SYSTEM_FLAG_CXX "-isystem ")
solves it, no more warnings generated for system files.
This is a very peculiar issue that appears only on OS X. On all other systems I tested, INCLUDE_DIRECTORIES(SYSTEM "/path/to/system/header") adds the headers as system headers, without any need to use the SET above.
Using export CXX=/opt/local/bin/g++ with several other system variables not adapted seems a little bit unorthodox, so the weird behavior is maybe not surprising.
I suggest you configure from scratch (=from a clean build directory) your project from cmake-gui, the menu allows you to specify the path to the compiler(s) you want to use. You can also use a custom tool-chain file. I suggest you use cmake-gui, it offers a couple of choice that might solve your problem.
Once you get it right, you can document the equivalent command line instruction for other people building your project.
I keep getting this error message while trying to Make this Azteroids project: "c++: error: unrecognized command line option ‘-stdlib=libc++’"
Based on what I've seen online, people are saying it's a Clang flag and the C++11 flag looks different. I mean, I don't disagree, but the instructions for creating the Azteroids executable are pretty simple and CMake seems to recognize C++11 support.
Is this a shortcoming of the cmake system in this project or am I missing a dependency or step? I don't understand. And yes, I've seen the similar questions.
Please see this Pastebin for more both the CMake and Make output.
Nothing in that output indicates that clang is involved here at all. Which is likely the problem.
It would seem that -stdlib=libc++ is a clang flag that your GNU c++ binary does not understand. Those flags are being manually added by the cmake configuration of that project. Which means it will not work without clang. So either remove those flags or install clang and configure cmake to use it.