I have a project I've been working for some time, always in debug.
Today I tried building a release, and it fails to compile throwing some very weird errors.
While the debug compiles without any warnings, release throws:
/usr/include/c++/4.7/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
Both CMake builds have c++11 enabled:
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -std=gnu++11 -Wall -g")
set(CMAKE_CSS_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -std=gnu++11 -Wall")
How can I track What is causing the compilation errors in Release?
EDIT I am using Cmake 2.8 and have tried to compile with gcc-4.6.3 and 4.7.2 and both have the same problem.
EDIT#2 Problem persists when using -std=c++0x instead of c++11.
EDIT#3 Downgrading to g++4.6 did not do much help. The error now simply changed to:
/usr/include/c++/4.6/bits/c++0x_warning.h:32:2:etc...
EDIT#4 I have removed <thread> which first caused problems. Then it was <mutex> and <atomic>. Now it is any piece of code that uses std::shared_ptr<Blah>.
It seems to me as if Release does not want to compile with C++11 at all. Is this on purpose?
I bet the problem comes from this line:
set(CMAKE_CSS_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -std=gnu++11 -Wall")
Look, you set the variable CMAKE_CSS_FLAGS_RELEASE. Chances are you just wanted to set the variable CMAKE_CXX_FLAGS_RELEASE instead. That would explain why your c++11 is not enabled in release mode.
I have fixed the problem by simply removing the CXX_FLAG, and using CMake's add definitions:
add_definitions("-std=gnu++11")
I do not know why this made it work, and why debug worked but release didn't, but it made a big difference.
Related
I am trying to use clang-tidy in my CMake (3.17.1) project however it crashes on the Catch2 test library header. Setting the Catch2 as a system header does not seem to help. The command invoked for clang-tidy contains the path to Catch2 as a system include directory yet the diagnostics is still printed for it. When trying to isolate it I have discovered that this does not actually work with clang-tidy:
clang-tidy src.cpp -- -Isystem/Path/to/header
It results in the header not being found at all. What I have learned somewhere (cannot find it now) was to make it actually two --extra-arg parameters of the clang-tidy instead:
clang-tidy --extra-arg=-Isystem --extra-arg=/Path/to/header src.cpp
This however does not work everywhere. On Windows I was able to make it work but on Linux it never worked in any form (together, separate, after --). How does one use the -isystem headers with clang-tidy on Linux? It is very confusing and inconsistent. Furthermore how to do it with CMake?
I have this:
cmake_minimum_required(VERSION 3.10)
set(CMAKE_CXX_CLANG_TIDY clang-tidy)
add_library(Catch2 STATIC Catch2/Catch2.cpp Catch2/include/Catch2/catch.hpp)
target_include_directories(Catch2 SYSTEM PUBLIC Catch2/include)
add_executable(SomeTest SomeTest/test.cpp)
target_link_libraries(Catch2)
The generated command line is rather convoluted (wrapping is mine for readability):
cmake
-E __run_co_compile
--tidy="clang-tidy-10;--extra-arg-before=--driver-mode=g++"
--source=../Sometest/test.cpp
--
/usr/bin/clang++-10
-isystem ../Catch2/include
-g
-std=gnu++17
-MD
-MT CMakeFiles/SomeTest.dir/projects/SomeTest/test.cpp.o
-MF CMakeFiles/SomeTest.dir/projects/SomeTest/FileTest.cpp.o.d
-o CMakeFiles/SomeTest.dir/projects/SomeTest/test.cpp.o
-c
../projects/SomeTest/test.cpp
In the output there are warnings from the Catch2 so the system in the include is just ignored seemingly. I have tried to force the --extra-arg via the CMAKE_CXX_CLANG_TIDY property:
set(CMAKE_CXX_CLANG_TIDY clang-tidy --extra-arg=-isystem --extra-arg=../Catch2/include)
but that does not seem to do the trick either.
I am following your repro as posted on LLVM bugtracker.
You are doing everything correctly: that is, marking Catch2 as system include with SYSTEM. clang-tidy is also behaving correctly: it only checks your source file test.cpp and doesn't fully check catch.hpp, only the macro expansion.
The problem is the outdated version of Catch2. hicpp-vararg warning has been silenced as of Catch2 2.12.2, so you need to update to at least that version. Moreover, apparently the core issue that hicpp-vararg reported upon has been fixed and this change is expected to be present in clang-tidy 11 release.
I'm using mingw-w64 (gcc 7.3.0) and when I compile any C++ program using the following command:
g++ file.cpp -fsanitize=undefined
I get the following error:
...mingw32/bin/ld.exe: cannot find -lubsan
I'm able to successfully compile and run my programs if I remove the -fsanitize=undefined flag, though. After some research I found out that this means the library ubsan (Undefined Behavior Sanitizer) is missing, but I couldn't find anything about the library. How do I fix this?
This is well known issue with mingw see for instance this msys github issue. No proper solution known but there are several WAs.
Install WSL, ubuntu over WSL and you will have ubsan inside it
Build GCC under Windows from source enabling sanitizers build. They are present in GCC sources they are just not here in mingw.
Use -fsanitize=undefined -fsanitize-undefined-trap-on-error to just not use libubsan rich logging capabilities but get it trap on undefined instruction.
Hope one of this helps.
I have been using cmake for a QNX 6.5 build which uses a qcc compiler. When I run make to build the project it does not show any errors (original project without the cmake did). This form was almost what I needed, but not quite. I tried to add the code below to my QNX_Toochian.cmake, but nothing happens. I suspect that it is because the qcc compiler needs a different flag then -Wall.
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
I also found this website which talks about setting the warning levels, but I still don't understand how to format this for my QNX_Toolchain.cmake.
One other resource that I found that does configure a QNX_Toochain.cmake is here. They also are setting flags for there build, but I don't know how to simply what they have done.
SET(CMAKE_CXX_FLAGS "-Vgcc_ntoarmv7le -lang-c++ -fstack-protector -fstack-protector-all -Wno-psabi -Wall -W -D_REENTRANT" CACHE STRING "Playbook QCC C++ Flags" FORCE)
So if anyone has an idea of how to get a QNX qcc cmake project to display errors that is what I am looking for.
I am using CMake 2.8.11 and GCC 4.8.2. I was building some C++ code which used std::shared_ptr which built fine in MS VS 2012 but when I tried the same on RHEL6 using GCC 4.8.2, I promptly ran into the following error:
error: 'shared_ptr' is not a member of 'std'
I found this question with responses that I thought addressed and I promptly added -std=c++11 to my CMAKE_CXX_FLAGS, but I still keep running into the error. I add the flag in CMake simply using:
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11" CACHE STRING "Add C++ 11 flags")
I set my custom compiler in CMake using:
SET(GCC_DIR "</path/to/custom>/gcc")
SET(CMAKE_CXX_COMPILER "${GCC_DIR}/bin/g++ CACHE FILEPATH "CXX compiler")
SET(CMAKE_C_COMPILER "${GCC_DIR}/bin/gcc CACHE FILEPATH "C compiler")
The include is
#include <memory>
which in turn has
#include <bits/shared_ptr.h>
which defines the shared_ptr class. So I'm not sure why I keep getting the error (and yes I cleared cached and rebuilt after adding the -std=c++11 compiler option). Any ideas are very much appreciated.
EDIT 1:
I created a simple program (main.cpp) as follows:
#include <memory>
#include <iostream>
int main() {
std::shared_ptr<int> pint = std::make_shared<int>();
std::cout << "Pint points to " << pint.get() << "\n";
return 0;
}
Then I built it using <path/to/custom/>g++ main.cpp -o prog and promptly ran into the same error (above). Next I did: <path/to/custom/>g++ -std=c++11 main.cpp -o prog and it compiles & runs OK. For my real application, I added the -std=c++11 flag to linker flags as well (in addition to compiler flags) in my CMake config system, but I still see the same error. Proceeding to check the CMakeCache to see if the flags are property registered, but any ideas are appreciated.
EDIT 2:
Suprisingly, I found in CMakeCache that the -std=c++11 flag is not being added to the CMAKE_CXX_FLAGS, etc. So this must have to do with the error. I am trying to fix it so that it actually takes this flag. Thanks all.
The answer confirms the hunch in EDIT 2 of my question. Apparently CMake 2.8.x is not appending to the variable CMAKE_CXX_FLAGS using the SET command using the syntax shown in my question (as per the documentation); I tried other variants of the SET command to append, to no avail.
So finally, instead of appending, I assigned separately for the case when C++11 is to be enabled and when it is to be disabled, as follows:
IF(USE_C++11)
...
ELSE(USE_C++11)
...
ENDIF(USE_C++11)
This worked fine. Thanks to #nos for the idea to make an isolated example.
When linking my project in the release mode I am getting the following warning:
myProject-libs/release/libboost_regex-mt-s-1.50.0.a(cpp_regex_traits.o): duplicate section `.data$_ZZN5boost16cpp_regex_traitsIcE21get_catalog_name_instEvE6s_name[boost::cpp_regex_traits<char>::get_catalog_name_inst()::s_name]' has different size
I suspect that the cause could be that the boost library is compiled with different options than I use for my project, but I don't know how to find the difference (boost didn't output these options during the build).
In order to compile the boost for win32 on Ubuntu 12.04 I used this procedure:
tar jxf boost_1_50_0.tar.bz2
cd boost_1_50_0
./bootstrap.sh
echo "using gcc : 4.6 : i686-w64-mingw32-g++ : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar ;" > user-config.jam
./bjam toolset=gcc target-os=windows --address-model=32 variant=release threading=multi threadapi=win32 link=static runtime-link=static --prefix=/opt/boost_1_50_0-release-static-windows-32 --user-config=user-config.jam -j 10 --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged install
In order to compile files in my project I use something like
i686-w64-mingw32-g++ -march=corei7 -mfpmath=sse -m32 -Wall -fmessage-length=0 -I"/opt/boost_1_50_0-release-static-windows-32/include" -std=c++0x -O3 -g0 -DNDEBUG -I"myProject/src/cpp" -c -o myProject/build/release/src/cpp/myproject.o myproject/src/cpp/myproject.cpp
The tests I have indicate that the regexps run fine but still I would like to resolve the warning.
EDIT
I found that additional options to the boost compiler can be added using a cxxflags= argument of bjam.
Example:
bjam cxxflags='-fPIC' ....
Maybe making sure to pass the same arguments as I do to the project could resolve the problem (particularly the arguments related to optimizations as suggested in the linked question).
Your compilers were compiled with different options :) Compiling the library on Linux and the program on Windows result in a situation where there is an identically named .data segment, but they aren't the same size. That could theoretically be interesting, inasmuch as a data segment is writable, but in practice, it shouldn't matter. Unless there is evidence to suggest this causes a problem of which I'm not aware, you can safely suppress that warning; I don't know how you'd make it go away, though.
I recently encountered this problem (i.e. linker warning "duplicate section has different size") when trying to compile boost for Windows using mingw.
The issue I had was that I compiled my application with -std=c++14 but when compiling boost I didn't specifically provide a dialect flag (which defaulted to -std=c++98 for g++ 5.3.0). Adding the dialect flag -std=c++14 when compiling boost solved the problem for me. See this answer for an explaination on how to set cxxflags when compiling boost.
I believe my solution might have worked for you (your application was compiled with -std=c++0x but boost was not provided any dialect flag). Although I am 6 years too late, I'll leave my answer here for others who happen to stumble-upon this issue.