I was compiling a code using LLVM and it failed compiling:
In file included from main.cpp:8:
In file included from /usr/lib/llvm-12/include/llvm/IR/LLVMContext.h:19:
In file included from /usr/lib/llvm-12/include/llvm/Support/CBindingWrapping.h:17:
/usr/lib/llvm-12/include/llvm/Support/Casting.h:309:7: error: cannot use 'throw' with exceptions disabled
throw runtime_error("Address sanitizer is not turned on.");
^
I realized my llvm-config is disabling the exceptions for me.
llvm-config-12 --cxxflags --ldflags --system-libs --libs core
Returns
-I/usr/lib/llvm-12/include -std=c++14 -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-L/usr/lib/llvm-12/lib
-lLLVM-12
In the past, I was not observing -fno-exceptions at all. A typical example should look like this.
Where does this exception prevention come from?
Related
To follow Kaleidoscope tutorial part 4, I downloaded the header file KaleidoscopeJIT.h. But once I include it, I get the following error
$ clang++ -g main.cpp kaleidoscope.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core orcjit native` -O3 -o kaleidoscope
In file included from kaleidoscope.cpp:18:
././include/KaleidoscopeJIT.h:21:10: fatal error: 'llvm/ExecutionEngine/Orc/ExecutorProcessControl.h' file not found
#include "llvm/ExecutionEngine/Orc/ExecutorProcessControl.h"
The closest information to it I could find at documentation page, but there is no information on how to successfully compile it. Any suggestions on how to resolve header dependency?
Here are my config options,
$ llvm-config --cxxflags --ldflags --system-libs --libs core orcjit native
-I/usr/lib/llvm-10/include -std=c++14 -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-L/usr/lib/llvm-10/lib
-lLLVM-10
Make sure you pull the correct files. You are using llvm-10 so you need to use the kaleidoscope tutorial from that version.
I recently installed LLVM v8.0.0 (on RHEL 7.4). I am going through the LLVM Kaleidoscope tutorial to learn how to use the system, but am running into an issue linking.
Per the tutorial (end of chapter 2), I run:
clang++ -g -O3 kld.cpp `llvm-config --cxxflags` -o kld
It compiles, but the linker fails on:
/tmp/kld-f7264f.o:(.data+0x0): undefined reference to `llvm::EnableABIBreakingChecks'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
I suspected this may have been an issue with llvm-config, so I also tried using the --ldflags and --system-libs flags, but no luck.
llvm-config --cxxflags gives (reformatted for readability)
-I~/project/llvm-src/include -I~/project/llvm-build/include
-fPIC -fvisibility-inlines-hidden
-std=c++11
-Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-g
-fno-exceptions -fno-rtti
-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
Where ~/... is just the path to my home directory (edited for privacy; the actual output is a fullpath). I am working on a shared system that requires I install new software locally.
The tutorial code never references ABI explicitly, so I assume this must be some kind of compiler-flags issue. greping for the missing symbol in non-binary files gives an extern declaration in include/llvm/Config/abi-breaking.h and the real declaration in lib/Support/Error.cpp:
#if LLVM_ENABLE_ABI_BREAKING_CHECKS
int EnableABIBreakingChecks;
#else
int DisableABIBreakingChecks;
#endif
I thought I would try re-compiling, then, with -DLLVM_ENABLE_ABI_BREAKING_CHECKS. That also does that work.
I'm not really clear what the ABI breaking checks are doing in the first place, and this may be way over my C++ comfort level. But how can I silence this error, if I don't need the referenced functionality; or fix it, if i do?
Thanks.
Turns out the answer was hidden in abi-breaking.h:
/* Allow selectively disabling link-time mismatch checking so that header-only
ADT content from LLVM can be used without linking libSupport. */
#if !LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING
I'm not sure if I'll need libSupport down the line, but compiling with LLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 works for the time being.
Add linkage with LLVMSupport library will also solve this problem.
With this CMake snippet:
find_package(LLVM REQUIRED CONFIG)
message(STATUS "Found LLVM ${LLVM_PACKAGE_VERSION}")
message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}")
add_executable(main main.cpp)
target_link_libraries(main LLVMSupport)
Based on the discussion in llvm irc channel.
Try the following command to compile : clang++ -O3 -c $(llvm-config --cxxflags) source_file.cpp -o obj_code.
Then try linking with this command : clang++ obj_code $(llvm-config --ldflags --libs) -lpthread.
I think linking part doesn't mentioned in the kaleidoscope section. The above solution worked for me.
I don't know the influence and reason why it works. But when I add -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING, the errors disappear.
clang++ xxx -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING
ref:
https://www.coder.work/article/6278120
https://blog.csdn.net/qq_37887537/article/details/112790961
I am on a complex project built in python2.7 that uses the PyDSTool package for analysis of dynamical system. PyDSTool provides two C-based integrators - Radau and Dopri - which I want to use to integrate my system of equations whose source is coded in a bunch of C/C++ files.
I have little control on the package, and when I instantiate the integrator, I can only add headers *.H files, source files (*.C, *.CPP) and pass the directories to include in the search path of the compiler as well as libraries to link to.
Since a consistent part of the code is based on C++11 I am passing to the compiler also the argument -std=C++11.
Eventually, /PyDSTool/Generators/mixins.py launch a setup command (line 185) which in turn runs the command build_ext from distutils to which all the above flags are appended.
For the sake of clarity: the flags that I am appending are:
compile options: '-I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c'
extra options: '-std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__'
The resulting compilation command as issued by PyDSTool reads:
error: Command "gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.c -o /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.o -std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__" failed with exit status 1
Once looking into the build.log file automatically generated by PyDSTool, it turns out that the exit status is due to the fact that the compiler does not see the C++ libraries that are in several routines/libs used by my code, e.g.
/usr/include/blitz/blitz.h:45:18: fatal error: string: No such file or directory
#include <string>
^
Compilation Terminated
Now, it is not a problem of my code, because if I compile my code as a standalone in python or through scipy.weave with the same compile and extra options pasted above, it works. It is a problem of making PyDSTool build the code within the integrator. As I am NOT practical with distutils and all gcc options I hope there is some expert here that could provide me with some insight. I suspect in fact that I am missing some options or whatever to pass to the compiler.
Just for the sake of completeness. The issue I pointed out above does not have an easy workaround. PyDSTool C-based integrators (i.e. Radau and Dopri) cannot be compiled with source code for the equations in C++ but only in C. So either you recast your code in plain C or try to edit PyDSTool integrators and recast them in C++. The first option is likely the only one currently possible (at least to some non-experts as who is writing).
I have been trying to install HEALPix over the last few days on my iMac and I am at something of a dead end as to how to proceed. When I run the necessary make command, I am told that the file string does not exist.
# compiling Healpix_cxx/syn_alm_cxx.cc
cd /Users/keir/Software/Healpix_3.11/src/cxx/build.osx/Healpix_cxx && g++ -I/usr/local
/include -I/Users/keir/Software/Healpix_3.11/src/cxx/c_utils -I/Users/keir/Software
/Healpix_3.11/src/cxx/libfftpack -I/Users/keir/Software/Healpix_3.11/src/cxx/libsharp
-I/Users/keir/Software/Healpix_3.11/src/cxx/cxxsupport -I/Users/keir/Software/
Healpix_3.11/src/cxx/Healpix_cxx -I/Users/keir/Software/Healpix_3.11/src/cxx/alice
-I/Users/keir/Software/Healpix_3.11/src/cxx/build.osx -Wall -Wextra -Wstrict-aliasing=2
-Wundef -Wshadow -Wwrite-strings -Wredundant-decls -Woverloaded-virtual -Wcast-qual
-Wcast-align -Wpointer-arith -Wold-style-cast -Wno-unknown-pragmas -Wfatal-errors -g
-fopenmp -fPIC -O2 -ffast-math -fomit-frame-pointer -ansi -fdata-sections
-ffunction-sections -c /Users/keir/Software/Healpix_3.11/src/cxx/Healpix_cxx/
syn_alm_cxx.cc
In file included from /Users/keir/Software/Healpix_3.11/src/cxx/Healpix_cxx/
syn_alm_cxx.cc:2:0:
/Users/keir/Software/Healpix_3.11/src/cxx/cxxsupport/error_handling.h:35:18: fatal
error: string: No such file or directory
#include <string>
^
compilation terminated.
make[1]: *** [/Users/keir/Software/Healpix_3.11/src/cxx/build.osx/Healpix_cxx/syn_alm_cxx.o] Error 1
I have had a look and it certainly does as is the whole of the libstdc++ library (I think). I have tried many solutions including re-installing Xcode and its Command Line Tools and trying various other versions of gcc (4.8, 4.9, 5.0 and a 4.9 copy from homebrew) - none of which solve the problem.
I have created a test file 'foo.cpp' with just #include <string> in it and this will still not compile even if I specify a directory for string with the -I tag, because it then can't find more headers that string depends on. It seems to me that libstdc++ isn't installed in the correct place? Or the '#include' command isn't looking in the right places? Do you have an idea as to how to fix this problem?
I'm developing applications in C++11 and my compiler is CLang++ 3.3. I'm also using Netbeans 7.3 IDE on Linux Mint 14.
All of my tests are done with GoogleTest (gtest-1.6.0) and almost everything is working fine except the warning mentioned in the title of this post.
Here's the command line executed by netbeans as an example:
clang++ -pedantic-errors -lgtest -pthread -c -g -Wall -std=c++11 -pedantic-errors -lgtest -pthread -MMD -MP -MF build/Debug/CLang-Linux-x86/_ext/1802678175/main.o.d -o build/Debug/CLang-Linux-x86/_ext/1802678175/main.o ../GIT_CryptoCode/src/main.cpp
I don't know why, but the command contains twice some attributes which gives the same warning twice of course. This is what I did in the project properties :
If I remove the Additional options, gtest is not working and the command line becomes something like this : clang++ -c -g -Wall -std=c++11 .... What should I do to not get some attributes to be duplicates ?
Well, even with cmake, I got the warning with Clang (which appears once this time :)). I also tested with GCC 4.7 and I didn't get any warning. Here's the command line I use in a cmake file for GCC :
set (CMAKE_CXX_FLAGS "-Winline -Wall -Werror -pedantic-errors -pthread -std=c++11")
Thus, Clang seems to be the problem. Is anyone know where this warning come from and how to remove it ? Is this a Clang bug ?
Thanks for your help.
I want to thank #Fraser for his help that helps me to find out the way to remove the warnings. Basically, instead of writing -pedantic-errors -lgtest -pthread in the Additional options of the C++ compiler section which gives a duplicate warning, these attributes should be in the Linker section of the project.
So, the Additional Options in the C++ compiler section are left empty. Now, I can use the -Werror attribute without any problem.
Also, in the cmake file, the line
target_link_libraries(${Project_Name} ${GTEST_BOTH_LIBRARIES})
links the gtest library to the project. Thus, no need of -lgtest in
set (CMAKE_CXX_FLAGS "-Winline -Wall -Werror -pedantic-errors -pthread -std=c++11")
both, for GCC and Clang.