I'm using clang-tidy to perform some analysis on my C++ code. For this, I'm using the Clang JSON compilation database. It is working on the development machine but I cannot reuse the compilation database on another machine because all the paths in the compilation database are absolute and the other machine does not have the same current working directory. Here is an example in the JSON:
{
"command": "clang++ -g -fprofile-arcs -ftest-coverage -Iinclude -std=c++1y -Wextra -Wall -Qunused-arguments -Wuninitialized -Wsometimes-uninitialized -Wno-long-long -Winit-self -Wdocumentation -pedantic -Iinclude -ICatch/include -Werror -MD -MF debug/test/algorithm.cpp.d -o debug/test/algorithm.cpp.o -c test/algorithm.cpp",
"directory": "/home/wichtounet/dev/cpp_utils_test",
"file": "test/algorithm.cpp"
},
Ideally, the directory, should be the current working directory. I tried replace the absolute directory path with "." and let it empty and also remove it, but nothing worked.
Currently, the only solution I have is to use a script replace all the previous absolute paths by the paths of the current working directory, but this is highly unpractical...
Is it possible to use the same compilation database on different machine ?
Related
I was building some Cython extensions, and have to link it against a static library (it has CUDA code in them, so have to be static):
running build_ext
building 'k3lib' extension
gcc -pthread -B /home/kelvin/anaconda3/envs/torch/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/kelvin/repos/tools/include -I/home/kelvin/anaconda3/envs/torch/include/python3.8 -c main.cpp -o build/temp.linux-x86_64-3.8/main.o -O3 -march=native
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
g++ -pthread -shared -B /home/kelvin/anaconda3/envs/torch/compiler_compat -L/home/kelvin/anaconda3/envs/torch/lib -Wl,-rpath=/home/kelvin/anaconda3/envs/torch/lib -Wl,--no-as-needed -Wl,--sysroot=/ build/temp.linux-x86_64-3.8/main.o /home/kelvin/repos/tools/include/libk2.a -L/home/kelvin/repos/tools/include -lk2 -o build/lib.linux-x86_64-3.8/k3lib.cpython-38-x86_64-linux-gnu.so -static -Wl,-Bstatic -flinker-output=exec
However, Cython's g++ compile command includes the options -shared -fPIC by default. I tried a number of options at the end of the command via this setup file (the static library is at $(LOCAL_INCLUDE)/libk2.a):
includes = [os.getenv("LOCAL_INCLUDE")]
ext_modules = [
Extension("k3lib", sources=["main.pyx"],
libraries=["k2"], include_dirs=includes, library_dirs=includes, language="c++",
extra_compile_args=["-O3", "-march=native"], extra_objects=[f"{includes[0]}/libk2.a"],
extra_link_args=['-static', '-Wl,-Bstatic', '-flinker-output=exec'])
]
#extra_objects=[f"{includes[0]}/libk2.a"]
#extra_link_args=['-static']
setup(name="k3lib", ext_modules=cythonize(ext_modules, language_level="3"))
Still, g++ thinks that I want to build a shared library, and thus the error message. Is there a way to override the -shared option? I'm planning to go into Cython's files and edit them myself, but was wondering is there a simpler way?
Context: I was following this question on SO but can't replicate their success.
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 running Netbeans 7.4 on Mavericks. In order to be able to use gdb, compilation with the -ggdb flag seems to be necessary. However, even though I specify it through the Project’s Properties/Additional Options wizard, Netbeans also emits -g during compilation. Unfortunately, it turns out that this behavior has an adverse effect when the debugging session commences. Is there any way to force Netbeans not to also emit -g?
Output during compilation:
g++ -m64 -ggdb -c -g -Werror -std=c++11 -MMD -MP -MF "build/Debug/macport_GNU-MacOSX/main.o.d" -o build/Debug/macport_GNU-MacOSX/main.o main.cpp
mkdir -p dist/Debug/macport_GNU-MacOSX
g++ -m64 -ggdb -o dist/Debug/macport_GNU-MacOSX/executable build/Debug/macport_GNU-MacOSX/main.o
Alexander.Simon#oracle.com responded here [1] to set "Development Mode" to "No Flags", then specify -ggdb in the "Additional Options".
1 - https://netbeans.org/projects/cnd/lists/users/archive/2014-02/message/12
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.