I try to compile a robot for torcs with the usage of opendavinci. The problem is that everytime i try to compile it
#error This file requires compiler and library support for the ISO C++ 2011 standard
appears. The obvious solution is to add the support, but i have a complicated makefile that is from torcs so i dont know how to work around this problem.
Is there any way to add the support without changing the makefile? I read about the CXXFLAGS that coud help me but i dont understand how it works.
The compiler is g++ 5.4.0 for Ubuntu
felix#ubuntufelix:/usr/src/torcs/torcs-1.3.7/src/drivers/bt$ make
g++ -I/usr/src/torcs/torcs-1.3.7/export/include -I/usr/src/torcs/torcs-1.3.7 -g -O2 -Wall -fPIC -fno-strict-aliasing -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES -Wall -fPIC -fno-strict-aliasing -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES -D_SVID_SOURCE -D_BSD_SOURCE -DSHM -DHAVE_CONFIG_H -c driver.cpp
In file included from /usr/include/c++/5/array:35:0,
from driver.h:15,
from driver.cpp:1:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
There's no completely standard way to build distributed software, but there should be a README or INSTALL file in the distribution, which gives more-or-less precise instructions. Ideally, distributions come with a configure script, and the installation process consists of ./configure; make; make install, possibly with some per-distribution special options given to ./configure. The basic process here is that the ./configure script edits suitable values into Makefile.in to generate Makefile, but such scripts can be arbitrarily complicated. Of course, things are rarely quite that simple, and building complicated software from source can be quite a technical challenge (this is why package managers are a Good Thing).
If there are no such installation instructions (have you double-checked?), then you should go back to the software distribution point and ask for help there (you're allowed to have a hint of reproach in your question as you do so – everyone, distributing even pre-beta software, should tell users how to build things).
If you've been left high and dry, however, then the following should broadly indicate where to look next:
You need to add an option to the invocation of the compiler, to tell it to support C++ 2011 features (I'm pretty sure g++ 5.4 has these features available, but they aren't enabled by default).
You do that by adding the -std=c++11 option to the compiler flags, and the way you do that is using the CXXFLAGS makefile variable that you measured (note: CXXFLAGS is the probable/conventional name for this variable, but it's not an inviolable rule).
Depending on how the Makefile is structured, you can add or adjust that variable in a number of ways.
Edit the Makefile – search for CXXFLAGS in the Makefile and add that -std option to that definition.
You will be able to redefine the variable on the make command line: make CXXFLAGS=-std=c++11, but that will stomp on any definition within the Makefile, which might be important.
The Makefile might be structured so that the definition includes CXXFLAGS=-foo -bar $(EXTRA_CXXFLAGS), which is there precisely so that you can call make with make EXTRA_CXXFLAGS=-std=c++11.
If there's a ./configure step to building this software, then there may be an option available to ./configure when doing that step (that doesn't sound like the case here).
But one way or another, your goal is to get -std=c++11 appearing in the compiler invocation that's produced by the Makefile. Note that if you give the -n option to make, then it will show you what commands it would produce, without actually doing anything.
Have fun.
Related
GDB documentation tells me that in order to compile for debugging, I need to ask my compiler to generate debugging symbols. This is done by specifying a '-g' flag.
Furthermore, GDB doc recommends I'd always compile with a '-g' flag. This sounds good, and I'd like to do that.
But first, I'd like to find out about downsides. Are there any penalties involved with compiling-for-debugging in production code?
I am mostly interested in:
GCC as the compiler of choice
Red hat Linux as target OS
C and C++ languages
(Although information about other environments is welcome as well)
Many thanks!
If you use -g (which on recent GCC or Clang can be used with optimization flags like -O2):
compilation time is slower (and linking will use a lot more memory)
the executable is a bigger file (see elf(5) and use readelf(1)...)
the executable carries a lot of information about your source code.
you can use GDB easily
some interesting libraries, like Ian Taylor's libbacktrace, requires DWARF information (e.g. -g)
If you don't use -g it would be harder to use the GDB debugger (but possible).
So if you transmit the binary executable to a partner that should not understand how your source code was written, you need to avoid -g
See also the strip(1) and strace(1) commands.
Notice that using the -g flag for debugging information is also valid for Ocaml, Rust
PS. Recent GCC (e.g. GCC 10 or GCC 11 in 2021) accept many debugger flags. With -g3 your executable carries more debug information (e.g. description of C++ macros and their expansion) that with -g or -g1. Of course, compilation time increases, and executable size also. In principle, your GCC plugin (perhaps Bismon in 2021, or those inside the source code of the Linux kernel) could add even more debug information. In practice, you won't do that unless you can improve your debugger. However, a GCC plugin (or some #pragmas) can remove some debug information (e.g. remove debug information for a selected set of functions).
Generally, adding debug information increases the size of the binary files (or creates extra files for the debug information). That's nowadays usually not a problem, unless you're distributing it over slow networks. And of course this debug information may help others in analyzing your code, if they want to do that. Typically, the -g flag is used together with -O0 (the default), which disables compiler optimization and generates code that is as close as possible to the source, so that debugging is easier. While you can use debug information together with optimizations enabled, this is really tricky, because variables may not exist, or the sequence of instructions may be different than in the source. This is generally only done if an error needs to be analyzed that only happens after the optimizations are enabled. Of course, the downside of -O0 is poorer performance.
So as a conclusion: Typically one uses -g -O0 during development, and for distribution or production code just -O3.
I've been doing C++ for a long long time, but I come from the land of Windows.
I've been handed a project that uses CMake. I've googled around trying to learn it.
I run cmake .
I assume it always looks for CMakeLists.txt and generates makefiles.
This creates a bunch more cmake files and make files.
I was then instructed to run make package.
I assume package is just a target name that could be anything.
I then get errors:
c++: error: unrecognized command line option ‘-mthumb-interwork’
c++: error: unrecognized command line option ‘-mfloat-abi=hard’
c++: error: unrecognized command line option ‘-mfpu=neon’
I think those are due to the fact that I am trying to compile for a different architecture then the one I am on. I assume all the cmake files would set that up correctly for me. I also assume that nothing there is proprietary.
I see the line in the CMakeLists.txt
SET(CMAKE_CXX_FLAGS "-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -std=c++11 -O3")
If I look at the official cmake documentation, it says, and I quote
"Flags for all build types." ....Not very helpful
I am thinking it isn't using the correct compiler, but I also don't see where in the CMakeLists.txt the compiler is specified at all.
The question is:
Why would these flags be unrecognized?
In the Linux world, it's often assumed that you don't need to specify the compiler by name; instead you arrange for c++ to refer to the compiler. That may involve setting PATH, creating a shell alias or a symbolic link.
Apparently you already did so, as your compiler is being called and is complaining about standard GCC flags - clearly your compiler isn't GCC.
The CMakeLists.txt file however is very much assuming it's intended for GCC. Don't blame CMake for that. CMake is the tool, CMakeLists.txt are project-specific instructions. This is a problem of whoever created the particular CMakeLists.txt file.
There's no easy fix. There is a real possibility that the -mfpu=neon option to gcc was necessary for the program, and it's anyone's guess what you'll need on the other compiler.
CMake has a nice framework for setting and defining an explicit value for the C++ standard, typically:
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_EXTENSIONS OFF)
However this does not clearly fit my needs, I'd rather states that I need at least c++11. I thought that I could just do instead:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.7)
project(p CXX)
set(CMAKE_CXX_EXTENSIONS OFF)
add_executable(foobar foobar.cxx)
target_compile_features(foobar PRIVATE cxx_nullptr)
where
$ cat foobar.cxx
int main()
{
char * p = nullptr;
}
However again in this case this forces me to use -std=c++11 eventhough by default g++ 6.3.0 default to -std=c++14 (technically -std=gnu++14):
$ c++ -dumpversion
6.3.0
leads to:
$ make VERBOSE=1
[...]
make[2]: Entering directory '/tmp/p'
[ 50%] Building CXX object CMakeFiles/foobar.dir/foobar.cxx.o
/usr/bin/c++ -std=c++11 -o CMakeFiles/foobar.dir/foobar.cxx.o -c /tmp/p/foobar.cxx
[100%] Linking CXX executable foobar
/usr/bin/cmake -E cmake_link_script CMakeFiles/foobar.dir/link.txt --verbose=1
Is there a way to say: "Build this project with at least C++11 Standard" in CMake ?
Typically for a project built using g++ 4.8.5 it would add -std=c++11 but for a project build with g++ 6.3.0 it would leave the default (implicit) -std=c++14
Update: The following is out of the scope for the question, but since I received a lengthy answer from #ComicSansMS, I feel I need to clarify the need for this.
I am working with my Debian Maintainer hat on, and I was convinced a couple of months back that setting an explicit C++ standard version in cmake within a project was the right way to do, hence my proposal:
Mandates explicit -std=c++XY for c++ projects
However there are two things that get mixed here:
Defining a c++ standard version for the interface of the library being built
Defining a c++ standard version for the implementation detail of the library being built.
From a Debian Maintainer perspective setting explicitly a C++ standard version makes it hard to rebuild a portion of the package archive when a library SONAME is being updated. Let's consider the case where GDCM is using the Poppler library. While the implementation details of GDCM are written using C++98, the fact that Poppler library has been build using the default (implicit) standard version of gcc-6 makes it suddenly a compilation failure for GDCM, since an explicit -std=c++98 is being passed.
So while for an implementation prospective, setting an explicit c++ standard version make sense (obviously!), it is a little less clear for an interface prospective. The vast majority of open-source projects do not define multiple c++ ABI (std::string[98] AND std::string[11]) and assume a single version will be used to ship the binary. In this case it makes it important for a c++ package to be build using the default (implicit) version of gcc (at least when uploaded as official Debian package).
You can always test for compilers support of the specific standard flags yourself.
First check for -std=c++14, and if it doesn't exist then check for -std=c++11, and if that doesn't work then error out.
Flags can easily be checked with the CheckCXXCompilerFlag module.
These days you should probably start with -std=c++17 though. You might also want to add checks for the pre-release standard versions like c++1z (for C++17) and c++1y (for C++14).
Start with the highest version, then work your way downward the minimum required version. Stop when it doesn't fail.
For newer versions of CMake you could use target_compile_features to specify features that the target compiler should be able to provide for.
This way, if (for example) your project uses auto type deduction you could tell CMake that the compiler need to suport the cxx_auto_type feature. Then CMake will make sure that the compiler can indeed support C++11 and the auto type deduction.
Is there a way to say: "Build this project with at least C++11 Standard" in CMake ?
No, and this is probably not a reasonable thing to request.
It does not make any sense to request a standards version that is newer than the code you are trying to build, as your code will not make any use of those features anyway.
The other big problem here is that newer standards are not strict supersets of older standards. In recent versions, the C++ standard has been quite keen on deprecating and even removing features that have outlived its usefulness.
What you have is a specific piece of code that expects a specific set of language features to be available. And that is exactly what you should tell the buildsystem. If your code expects the C++11 features to be available, set CMAKE_CXX_STANDARD to 11 and be done with it. It will guarantee that all of the required features are available and safeguard you (within reasonable bounds) against any future deprecations.
Now, there is one scenario where specifying an exact standard is not enough: You might have different implementations in your code and then want to switch between implementations depending on the available compiler capabilities. That is, your code might be C++14 aware and you want it to compile in C++14 mode if available, but still leave the C++11 mode as a fallback.
This is exactly the default behaviour of CMAKE_CXX_STANDARD:
This means that using:
set_property(TARGET tgt PROPERTY CXX_STANDARD 11)
with a compiler
which does not support -std=gnu++11 or an equivalent flag will not
result in an error or warning, but will instead add the -std=gnu++98
flag if supported. This “decay” behavior may be controlled with the
CXX_STANDARD_REQUIRED target property.
So in a nutshell, always specify the latest standard that your code is aware of, but not newer.
I'm doing a tutorial right now that doesn't make it to clear on how to do this.
I have two files, int2.cpp which has my main and int1.cpp which is a function (int2 calls on int1) I know they will work but how would one type it into the command line? tutorial says g++ int2.cpp int1.cpp -o int2.cpp, but it says " g++ is an illegal command"
I'm using DOSbox 0.74.
I compile things with tcc sorry but it says -o isn't a command line option
I compile things with tcc sorry but it says -o isn't a command line option
TurboC++ is an obsolete compiler (for an obsolete variant of C++); don't use it.
TinyC (e.g. the tcc command) is a compiler for C, not for C++.
C and C++ are different languages, and you want to learn at least C++11 (since older standards of C++ are obsolete and very different, it is not worth learning them in 2017).
So get and use a free software C++11 compiler like GCC or Clang. BTW both are easily available on most Linux distributions (which I recommend you to use).
Of course you'll want to compile with warnings and debug information, so use
g++ -Wall -Wextra -g with GCC and clang++ -Wall -Wextra -g with Clang.
BTW, you probably want to compile several translation units into a single executable binary. This often involves a linking step (i.e. running the linker on several object files, also using the g++ command). Consider learning to use some build automation tool like GNU make (which has a lot of builtin rules to help in doing that).
g++ is an illegal command means the compiler is not installed on your path. The syntax is (almost) right, you likely just don't have gcc installed.
g++ int2.cpp int1.cpp -o int2.exe
I'm using some features in my C++ programs that I need -std=c++11 option set in g++
Is it possible set this option as a default and don't be necessary use this all time I compile it?
Or how to set this in Makefile.
Yes, you typically set this in a Makefile:
CXXFLAGS=-std=c++11
One layer above you can also detect a suitable compiler via autoconf, cmake or whichever other meta-buildtool you might deploy.
You of course play games as define g++11 as g++ -std=c++11 but such set-ups are not portable.
g++-6.* will default to c++14 so at some this switch will be implicit. But it might take a really long time for all those RHEL and CentOS boxen with g++-4.4.* to disappear. Those may not even handle your current project...
Yes, upgrade to GCC 6.1:
The C++ frontend now defaults to C++14 standard instead of C++98
From https://gcc.gnu.org/ml/gcc/2016-04/msg00244.html
You can have a makefile do this as follows (this is a simple version with no variables).
out: source.cpp
g++ -std=c++11 source.cpp -o out
Use your build system of choice. Be that make, SCons, CMake, qmake or something else, and set the required option. Should take all of 30 seconds and you're done.
Or, upgrade your compiler to a version that uses C++11 by default.