I have gcc 4.8.5 installed on a Red Hat 7.5 machine.
I wish to compile a software package on this machine.
In order to compile this package, I need to run "make".
However, when I run this, I see the following error message "error: ‘make_unique’ is not a member of ‘std’".
My understanding (possibly incorrect) is that this message originates from the fact that 4.8.5 uses C++11 and "make_unique" requires C++14. So I presume the way to compile this is to specify that C++14 should be used when I run "make".
How do I do this ?
I have tried to set the C++ to 14 as follows:
cmake -G "Unix Makefiles" -D CMAKE_CXX_STANDARD=14
And then I ran "make".
But this gave the same error message.
You are using compiler that does not support C++14. As stated in the documentation:
GCC supports the original ISO C++ standard (1998) and contains experimental support for the second ISO C++ standard (2011).
It is no surprise, since GCC 4.8 was originally released in 2013 so it would be weird if it implemented a standard introduced a year later.
To use C++14 or even C++17 you can compile it with RH Devtoolset 8. The built software would run on target OS w/o any additional effort due to the "nature" of DTS compiler: the symbols available in the OS-shipped libstdc++ gonna be resolved dynamically, while C++11 and above gonna be linked to you executable from the specially built static libstdc++.a provided by DTS.
Related
I am compiling one code repository which has a makefile,
make INSTALL_PREFIX=/usr/local install
and I get the following 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.
How can I enable ISO C++ 2011 standard?
Thanks,
You don't give any details on the code repository, does it use just a standard makefile, autotools, cmake ?
You may be able to just do a export CPPFLAGS="-std=c++11" prior to building building the code.
I want to use latest gcc compiler, but target pc configuration only has libstdc++/libc suitable for gcc 4.8.
Is there any way to tell compiler to link against older abi?
I've managed to run my application, built with newer compiler (gcc 6), when I used -std=gnu++11 flag. It seems explicitly specifying standard version makes compiler link to maximum required version of abi.
it's supposed g++ (tdm-1) 4.7.1 that comes with codeblocks for windows support all C++11 features, std::stoi(str) isnt reconized, same for other c++11 functions. (string header is included).
Do i need to look for another compiler ?
This is due to missing C library functions in MinGW, see the last few comments on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
I made some improvements so it is supported in MinGW GCC 4.9 and later, so you could just upgrade to a later TDM build.
I'm trying to integrate Octave interpreter into my rigid body simulator compiled with GCC 4.8.1.
Following steps posted in the official documentation (https://www.gnu.org/software/octave/doc/interpreter/Standalone-Programs.html) allow me to compile, link, and successfully execute the first example. Note, that I can link the executable with both mkoctfile.exe, or g++ when minGW 4.8.1 is added to PATH.
However, the second example showing how to embed the interpreter into my program compiles, links, and then segfaults on execution when GCC 4.8.1 binaries are in PATH. It works, when I use the supplied compiler (in my case it's gcc 4.6.2 shipped with octave 3.6.1 on windows).
Do I need to build octave from source using GCC 4.8.1 in order to successfully link program compiled using that version, or is there any other way to do so?
Using GCC 4.6.2 is not an option for me, as my program uses c++11 features not present in that version.
I just learned that there is a newer Octave version available at http://mxeoctave.osuv.de/ which was compiled with GCC 4.9.2. This version of GCC works for me perfectly and the second example provided in the documentation started to work when compiled with g++ provided with the distribution.
The question is about a specific combination of versions but is relevant more generally.
I've just dist-upgraded from Kubuntu 12.04 to 14.04. Now, when I want to compile CUDA code (with CUDA 6.5), I get:
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
I installed gcc-4.8 (and 4.7), and tried to use the symlinks-in-/usr/local/cuda/bin solution suggested here:
CUDA incompatible with my gcc version
but this doesn't work. What should I do?
This solution is relevant to multiple combinations of CUDA and GCC versions.
You can tell CUDA's nvcc to use a specific version of gcc. So, suppose you want gcc 4.7 for use with CUDA 6. You run:
sudo apt-get install gcc-4.7 g++-4.7
and then add the following switch to your nvcc command-line:
nvcc --compiler-bindir /usr/bin/gcc-4.7 # rest of the command line here
If you're building with CMake, add an appropriate setting before looking for CUDA to your CMakeLists.txt, e.g.:
set(CUDA_HOST_COMPILER /usr/bin/gcc-4.7) # -> ADD THIS LINE <-
find_package(CUDA)
Also, it seems clang can compile CUDA as well, maybe that's worth experimenting with (although you would have to build it appropriately).
Note: Some Linux (or other OS) distributions don't have packages for multiple versions of gcc (in the same release of the OS distribution). I would advise against trying to install a package from another release of the distribution on an older release, and consider building gcc instead. That's not entirely trivial but it is quite doable - and of course, it's your only option if you don't have root access to your machine.
Switch back to a supported config. They are listed in the getting started document for any recent CUDA distribution.
For your particular configuration you have currently listed, you might have better luck with CUDA 7 RC, which is now available to registered developers.
I had a similar issue with CUDA Toolkit 7.5 and gcc 5.2.1.
I did modify the host_config.h file in /usr/local/cuda/include/:
Just remove the lines where it check the gcc version. It did solve my problem.
Credits goes to Darren Garvey (https://groups.google.com/forum/#!topic/torch7/WaNmWZqMnzw)
Very often you will find that CUDA has had newer releases by the time you encounter this problem. For example, the original formulation of the question was about CUDA 6 and GCC 4.9; CUDA 7 supported GCC 4.9. CUDA 8 supports GCC 5.x . And so on.