Why CMake does not seem to apply -pthread using add_compile_options command? - c++

I am trying to compile a simple C++ program using g++ 4.8.2 using CMake 2.8.12.2 which makes use of C++11 features and also multithreading. For that, compiler flags -std=c++11 and -pthread must be used. From my understanding, in CMake, setting these flags can be done in various ways, one is to use the set command:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread")
The other (supposedly preferred) way is to use add_compile_options command:
add_compile_options(-std=c++11)
add_compile_options(-pthread)
(Or in one line: add_compile_options(-std=c++11 -pthread))
So, the problem is that in my case, only the first method works - by using the set command. The problem is with using the add_compile_options which results in crash of the compiled output executable with the following message (just like the -pthread was not specified at all):
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)
The code I test with:
#include <future>
int main()
{
auto a = std::async(std::launch::async, [](){});
a.wait();
return 0;
}
From the fact that this program compiles, I can infer that -std=c++11 was applied. The question is that why -pthread is not applied?

Assuming that you are definitely compiling with g++ (just worth clarifying by checking what /usr/bin/c++ actually is - I'm presuming it's a link to g++) The man page for g++ gives:
gcc [-c|-S|-E] [-std=standard]
[-g] [-pg] [-Olevel]
[-Wwarn...] [-pedantic]
[-Idir...] [-Ldir...]
[-Dmacro[=defn]...] [-Umacro]
[-foption...] [-mmachine-option...]
[-o outfile] [#file] infile...
which implies that you need to have:
g++ -std=c++11 -g -pthread ...
in that order.
Perhaps it's worth trying running your command line manually with this adjustment to see if what's produced works as you'd expect.
It looks to me (without any research, I'd add) that add_compile_options might only be useful for adding strict compiler options, so you might have to use set to set -std=c++11 and add_compile_options for all other compiler options - i.e. specified after -g

Try the following:
set (
CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS} "
"-Wall -Werror -pthread -std=c++11 -Wl,--no-as-needed"
)
source: here

Related

In Visual Studio Code: "no template named 'initializer_list' in namespace 'std'"? [duplicate]

I wanted to compile C++11 source code within Mac Terminal but failed. I tried g++ -std=c++11, g++ -std=c++0x, g++ -std=gnu++11 and g++ -std=gnu++0x but nothing worked. Terminal always read unrecognized command line option. However, g++ -std=gnu and things like that worked fine (of course C++11 source code could not pass).
Which option should I use to turn on C++11 support?
By the way, the command line tool I'm using is installed within Xcode, and I'm pretty sure that they are up-to-date.
As others have pointed out you should use clang++ rather than g++. Also, you should use the libc++ library instead of the default libstdc++; The included version of libstdc++ is quite old and therefore does not include C++11 library features.
clang++ -std=c++11 -stdlib=libc++ -Weverything main.cpp
If you haven't installed the command line tools for Xcode you can run the compiler and other tools without doing that by using the xcrun tool.
xcrun clang++ -std=c++11 -stdlib=libc++ -Weverything main.cpp
Also if there's a particular warning you want to disable you can pass additional flags to the compiler to do so. At the end of the warning messages it shows you the most specific flag that would enable the warning. To disable that warning you prepend no- to the warning name.
For example you probably don't want the c++98 compatibility warnings. At the end of those warnings it shows the flag -Wc++98-compat and to disable them you pass -Wno-c++98-compat.
XCode uses clang and clang++ when compiling, not g++ (assuming you haven't customized things). Instead, try:
$ cat t.cpp
#include <iostream>
int main()
{
int* p = nullptr;
std::cout << p << std::endl;
}
$ clang++ -std=c++11 -stdlib=libc++ t.cpp
$ ./a.out
0x0
Thanks to bames53's answer for pointing out that I had left out -stdlib=libc++.
If you want to use some GNU extensions (and also use C++11), you can use -std=gnu++11 instead of -std=c++11, which will turn on C++11 mode and also keep GNU extensions enabled.

qcc - CMake and compiler warnings

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.

Automatically select a C++11-compatible g++ version in the Makefile

The problem:
2 version of g++ installed on a computer running Ubuntu 12.04. They are the versions 4.6 and 5.2.
I have to compile a C++11 program using a Makefile. If I use g++ as compiler it calls automatically the version 4.6, it does not support c++11 so the compilation fails. I've followed a tutorial online, so that now if I call g++ it calls automatically the version 5.2 and now it works.
I find this solution not so good, since it works only on my PC. Is there a way to recognize in the Makefile if the default g++ version support C++11 and, in case not, switch to a more recent version?
Thank you!
Is there a way to recognize in the Makefile if the default g++ version support C++11 and, in case not, switch to a more recent version?
You can certainly detect the version of the default compiler available in PATH in your makefile. However, where do you search for another version?
The standard approach is to let the user specify the C compiler through CC and C++ compiler through CXX make variables, e.g.: make CC=/path/to/my/gcc CXX=/path/to/my/g++.
You can always select which gcc to use while invoking make
make CXX=/gcc/path/of/your/choice
otherwise you can detect gcc version using
ifdef CXX
GCC_VERSION = $(shell $(CXX) -dumpversion)
else
GCC_VERSION = $(shell g++ -dumpversion)
endif
in Makefile and while using, you can test if your gcc is >=4.6
ifeq ($(shell expr $(GCC_VERSION) '>=' 4.6), 1)
UPDATE: newer gcc needs -dumpfullversion together (icx is the CC from Intel OneAPI)
$ icx -dumpversion
14.0.0
$ gcc -dumpversion
9
$ icx -dumpfullversion -dumpversion
14.0.0
$ gcc -dumpfullversion -dumpversion
9.3.1
One very simple way is to use conditional statements in your makefile, and go for versions which you know are compatible, and only use the default gcc as a fallback. Here's a basic example:
CXX=g++
ifeq (/usr/bin/g++-4.9,$(wildcard /usr/bin/g++-4.9*))
CXX=g++-4.9
# else if... (a list of known-to-be-ok versions)
endif
The other, more robust method, is to generate your makefile using a script that checks for capabilities using test compilations, kind of like what ./configure usually does. I really don't mean to recommend autotools, though.
The thing to do is build your Makefile to use as many implicit rules as possible. By default compilation uses various environment variables.
The variable $(CXX) is the C++ compiler command and defaults to g++ on Linux systems. So clanging CXX to a different compiler executable will change the compiler for all implicit compile commands.
When you write explicit rules use the same variable that the implicit rules use. So instead of this:
program: program.cpp
g++ -o program program.cpp
Do this:
program: program.cpp
$(CXX) -o program program.cpp
Other variables you should use are:
CPPFLAGS = -Iinclude
CXXFLAGS = -std=c++14 -g3 -O0
Those are for pre-processing flags CPPFLAGS and compiler flags CXXFLAGS and library linking flags LDLIBS.
Using the default environment variables allows the person compiling the project the freedom to control the compilation for their desired environment.
See the GNU make manual
This works for me:
cmake_minimum_required(VERSION 2.8.11)
project(test)
if (${CMAKE_CXX_COMPILER_VERSION} LESS 5.0)
message(FATAL_ERROR "You need a version of gcc > 5.0")
endif (${CMAKE_CXX_COMPILER_VERSION} LESS 5.0)
add_executable(test test.cpp)
You can check in your source code the gcc version and abort compilation if you don't like it. Here is how it works:
/* Test for GCC > 4.6 */
#if !(__GNUC__ > 3 && __GNUC_MINOR__ > 6)
#error gcc above version 4.6 required!
#endif

Error: ‘to_string’ is not a member of ‘std’ when compiling in command line with gcc 4.8.2, works in NetBeans?

I am doing tests for my code with GoogleTest (1.7.0). I must have the tests compiling in both NetBeans (8.0.2) and straight from command line.
NetBeans has GoogleTest integrated as suggested here: https://youtu.be/TS2CTf11k1U.
I have also build GoogleTest from the command line (in different place) with the instructions provided with the package.
The problematic line of code is (a and b are doubles):
std::string input = std::to_string(a) + " " + std::to_string(b);
which gives error: ‘to_string’ is not a member of ‘std’, when compiling with
g++ -isystem -std=c++0x ~/gtest-1.7.0/include -pthread ~/Task1/test_source.cpp libgtest.a -o test_module1_1
as instructed in GoogleTest documentation.
The strange thing here is that when using the "Test" from NetBeans (as seen on video), the tests compile and run correctly.
I am using Ubuntu 14.04 and I have already tried to update g++ (not to a higher version though), and I have also tried specifying the version with -std=c++11 instead of -std=c++0x.
In NetBeans there is this warning visible:
Library File /usr/include/c++/4.8/string
but there is an unresolved #include <stddef.h>
in included /usr/include/_G_config.h
I found out that this might be because multilib and I have also tried to fix that by checking that it is installed. And this doesn't really cause any warnings during compile so it might be just that the IDE is confused.
But conserning the real problem about compile errors:
Is there something wrong with the GoogleTest framework, the compiler or my code?
PS. Preferably don't suggest that I just don't use to_string as this system must be usable by students studying C++11 and really it shouldn't be that they can't use all the functionality that should be supported.
I think your problem is the order in which you're passing command line arguments to gcc
g++ -isystem -std=c++0x ~/gtest-1.7.0/include ...
^^^^^^^^^^^^^^^^^^^
The -isystem flag should be followed by a path that contains headers which you want gcc to treat as system headers. So the -std=c++0x flag is being incorrectly consumed by the -isystem flag. You probably want the command line to be
g++ -std=c++0x -isystem ~/gtest-1.7.0/include ...

Configuring g++ from Code::Blocks doesn't take affect on command line

I'm trying to change the settings of g++ from the Code::Blocks IDE. I went to the Settings tab, clicked Compiler... and checked various options for the compiler to use, like
Enable all warnings (-Wall)
Have g++ follow the C++11 ISO C++ language standard (-std=c++11)
......
These are just two of many others; when I compile on the command line, here is what comes up:
g++ -o example example.cpp
# warning: initializer lists only available with -std=c++11 ...
Notice how there's no warning either - I have an unused variable in my program. It only works if I give the options manually:
g++ -Wall -std=c++11 -o example example.cpp
Do you think I might have done something wrong when setting up the compiler? Why aren't the options taking affect?
Invoking the compiler from the ide is completely independent from doing it in a command line shell. There's no reason for the setting and usage of one to have any effect on the other.