Is there any way to let clang ignore errors when compiling the code? Such as the missing header errors.
I am using -emit-llvm option of clang to compile some programs to llvm bitcode, however, I don't care if some header file is missing.
Related
I am running clang-tidy checks using cmake version 3.20.0-rc1 on Windows 10.
My project builds using GNU 8.3.0.
Sadly I get the error
error: 'cstddef' file not found [clang-diagnostic-error]
#include <cstddef>
clang-tidy info:
LLVM (http://llvm.org/):
LLVM version 12.0.0
Optimized build.
Default target: i686-pc-windows-msvc
Host CPU: skylake
[clang-diagnostic-error] is basically a compiler error coming from the clang backend.
Clang-tidy needs an AST (abstract syntax tree) - your code has to be compileable by clang compiler in order to generate an AST. Only then will clang-tidy analyze your code.
Get your code to compile by clang instead of GCC and you should find the source of your problem.
I am trying to install cilk++ according to this website and am at the steps in section "Cilk Plus Runtime". When I go to build, I get the following output:
$ cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=./install ..
CMake Error at CMakeLists.txt:132 (message):
CXX compiler must support Cilk.
-- Configuring incomplete, errors occurred!
See also "/Users/anthonymcknight/Documents/cubing/bfs/lab4/cilk/cilkrts-0.1.2/build/CMakeFiles/CMakeOutput.log".
See also "/Users/anthonymcknight/Documents/cubing/bfs/lab4/cilk/cilkrts-0.1.2/build/CMakeFiles/CMakeError.log".
I thought clang and clang++ (which I checked with --version are indeed installed) would be sufficient. Do I need to update clang and clang++? There are no troubleshooting steps on the instructions website, so I'm not sure what I need to do to finally get cilk++ up and running on my laptop.
Thanks in advance,
Anthony
Expanding on my comment:
When you configure this Cilk Plus Runtime with CMake, CMake first verifies the compiler by attempting to compile a simple test program (see here). If the compilation fails, CMake prints the error you see:
CMake Error at CMakeLists.txt:132 (message):
CXX compiler must support Cilk.
On the Intel Cilk Plus runtime Github page (cilkrts), it has some compiler requirements listed for those trying to build this library:
You need the CMake tool and a C/C++ compiler that supports the Cilk language extensions. The requirements for each operating systems are:
Common: CMake 3.4.3 or later Make tools such as make
Linux: Tapir/LLVM compiler, or GCC* 4.9.2 or later (depracated), or Cilk-enabled branch of Clang*/LLVM* (http://cilkplus.github.io), or Intel(R) C++ Compiler v12.1 or later (depracated)
OS X: Tapir/LLVM compiler, or Cilk-enabled branch of Clang*/LLVM* (http://cilkplus.github.io), or Intel C++ Compiler v12.1 or later (depracated)
Since you are using Clang as your compiler, be sure it is a Cilk-enabled branch of Clang, as specified in the requirements. Or, you can try to use the Tapir/LLVM compiler.
I'm trying to convert a java library to objective-c using j2objc and include the generated objc files into my XCode project. I managed to generate the objc files, but XCode gives me the following error: https://i.stack.imgur.com/QX3zF.png
I used lipo -info on a .o file and I get this "architecture: x86_64". Does it mean those objc files are not meant to run on arm64 architectures and if so, how can I solve this ? Are there any flags I could use to generate the files for arm64 ?
A previous error I had was "ARC forbids explicit message" and I solved this by adding a compiler flag -fno-objc-arc to all the compile sources related to this error. Is this solution safe ?
To compile for arm64, the -arch arm64 and -isysroot IPHONE_SDK_DIRECTORY flags are needed. To find the IPHONE_SDK_DIRECTORY on your system, run xcrun -sdk iphoneos --show-sdk-path.
There's nothing J2ObjC-specific about this, they are normal iOS flags you'll find in you look at the log of a successful compile of an Objective C file in Xcode and click its right button to expand and show all the flags used.
J2ObjC by default does not generate ARC code, so the -fno-objc-arc flag is okay. If you would prefer ARC, run j2objc with its -use-arc flag. Don't compile those generated files with -fno-objc-arc, however, as objects won't be released when your app is finished with them.
I am new to cmake.
I have seen that doing export CXX=g++ tells cmake to use the g++ compiler for the .cpp files for instance.
I also read that if we don't pass any compiler with CXX, it will search for a compiler with name cc, gcc, cl, bcc, xlc, clang (in that order). But if we don't export any compiler, is there an easy command to know what compiler exactly cmake use for the .cpp files for instance? Will it always be g++ if we have it installed?
Turning my comment into an answer:
You can get the C and C++ compiler names from the variables CMAKE_CXX_COMPILER and CMAKE_C_COMPILER like gcc, g++, cl, or clang. With the variables CMAKE_C_COMPILER_ID and CMAKE_CXX_COMPILER_ID you get the identifier of the compiler like GNU, LLVM, or AppleClang.
When compiling Objective-C from the command line (gcc), what are some good flags to use? Many of the standard C flags (-Wall, -ansi, etc) don't play well with Objective-C.
I currently just use -lobjc and -frameworkwith various frameworks.
Many of the standard C flags (-Wall, -ansi, etc) don't play well with Objective-C
-Wall works perfectly fine with Objective-C.
The thing to do is build an Objective-C file with Xcode and have a look at the build transcript. I've just done that and here are some highlights:
-x objective-c I guess that means "compile as Objective-C", probably important
-arch x86_64 build for a particular CPU architecture
-std=gnu99 build for C99 + GNU extensions (actually surprised me, I thought Xcode used -std=c99).
-isysroot .... specifies the location of the SDK.
-mmacosx-version-min=10.6 I am compiling for 10.6 and up
-fobjc-gc-only this file was intended to be used with garbage collection and won't work without it, so I compile for GC only.
-Wall the obvious.
If you are compiling from the command line, it's probably a good idea to set the option to treat warnings as errors. I don't from within Xcode because the build results window remembers the uncleared warnings from previous builds.