I tried to set g++ to compile in c++11. I read that i need to use the flag, -std=c++11, but it's not aviailable at my g++ version(4.2.1), and there's not clear information about updating it. What should i do?
Related
My code is compiled using the g++ compiler version 4.9.0. I'm using C++11.
However, the compiler doesn't understand the nullptr keyword. Here is what I've found out:
This is not a typo, because the word nullptr is displayed in bold in the editor.
g++ supports nullptr, because its version is greater than 4.6.0.
The compiler understands that I want to use C++11, because it doesn't complain when I use auto or decltype one line earlier (I use the -std=c++0x command-line argument, but I also the -std=gnu++0x).
I have no idea what else can be wrong, so I'll be grateful for any suggestions.
Edit: the error message is the following:
error: nullptr was not declared in this scope.
This is the output of the
g-- version command:
g++ (OSE 4.9.2-2 20160202) 4.9.2
The flag in recent versions of g++ is -std=c++11.
My code is compiled using the g++ compiler version 4.9.0. I'm using C++11.
No it isn't, it's being compiled with GCC 4.5, or older. Otherwise nullptr would work.
This is the output of the g-- version command:
g++ (OSE 4.9.2-2 20160202) 4.9.2
Well that's certainly not 4.9.0, what is OSE?
How are you compiling your code? Because it seems to be finding a different version of GCC, not that one.
std::chrono ought to be supported in g++ 4.8.*. However, when I try to compile using it using g++ 4.8.3, it cannot find various declarations. I am, of course, using -std=c++11.
For example this invocation (from an autogenerated file; that's why the -std appears twice):
g++-4.8 -g -msse2 -m64 <defines> <warnings> -std=c++11 -fexceptions -std=c++11 <includes'-path> -c <source-file.cpp> -o <out-path>
Produces this error:
<source-file, line>: error: ‘std::chrono::monotonic_clock’ has not been declared
I wasn't able to find very much that wasn't immediately a compiler version or missing -std=c++11. By inference from this, I shouldn't need anything else.
Question: what's wrong, how do I fix it?
There is no std::chrono::monotonic_clock in standard C++. There is a std::chrono::steady_clock, however.
In fairness to Microsoft - and burritos everywhere - there was a monotonic_clock in the working drafts during the development of C++11 which was replaced by steady_clock.
It seems to me that you could use code like this to determine whether you're using an old library implementation (that provides monotonic_clock but not steady_clock) or a new one (that provides steady_clock but possibly not monotonic_clock).
#if defined(__GLIBCXX__) && (__GLIBCXX__ < 20120322)
typedef std::chrono::monotonic_clock steady_clock;
#else
typedef std::chrono::steady_clock steady_clock;
#endif
The datestamp above corresponds to the libstdc++ shipped with GCC 4.7.0, according to GNU. I'd welcome any improvements or corrections to this code, for example to support libraries other than libstdc++.
One of my users is getting an error message when trying to compile a C part of our mixed C/C++ codebase on ubuntu 12.04 with gcc 4.8.1
We have a library in C++ with some C-linkage functions in, and want to compile a C program linking to it. The library is compiled with g++ and builds fine. The c program fails like this:
> gcc -O3 -g -fPIC -I/media/Repo/lcdm/code/cosmosis/ -Wall -Wextra -pedantic -Werror -std=c99 -o c_datablock_t c_datablock_test.c -L . -lcosmosis
cc1plus: error: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [-Werror]
The program has a lower case .c file suffix, so why does gcc try to compile it as c++ ? We have not seen this on other OSes.
(I know we could kick the problem down the road by removing -Werror or handle this particular file with -x c but I'd like to solve the real problem.)
why does gcc try to compile it as c++
I can think of only two plausible explanations, and they both are end-user's fault.
It could be that the user transferred sources via Windows, and the file is really called C_DATABLOCK_TEST.C, and the user is misleading you.
It could also be that the user overwrote his gcc with g++ (surprisingly many people believe that gcc and g++ are the same thing, but they are not).
To disprove the first possibility, ask the user to execute his build commands under script, and send you resulting typescript.
To disprove the second, ask the user to add -v to the compile command.
This look like GCC Bug 54641, which has been fixed in a later release of GCC. It is only a warning, but your compile flags are causing GCC to treat all warnings as errors.
I'm trying to build google-glog on Mac OS X 10.8, using following options:
./configure CXX='clang++' CXXFLAGS='-std=c++11 -stdlib=libc++'
Despite that the library gets linked with libstdc++.
Why, and how to fix this?
It's better to put 'dialect' and runtime flags in the compiler variable, since it will use those flags for linking - not just source compilation: CXX="clang++ -std=c++11 -stdlib=libc++"
Save CXXFLAGS for things like -W -Wall -O2 -march=xxx, etc.
Found out that you could use the build variable
LIBS+="-stdlib=libc++"
Seems to me a better place than the compiler variables.
I figured out that CUDA does not work in 64bit mode on my mac (or couldn't get it running so far). Therefore I decided to compile everything for 32bit.
I use cmake 2.8 and added the following options
add_definitions(-Wall -m32)
set(CUDA_64_BIT_DEVICE_CODE OFF)
set(CMAKE_MODULE_LINKER_FLAGS -m32)
However when it tries to link it it does something like this:
/usr/bin/c++ -mmacosx-version-min=10.6 -Wl,-search_paths_first -headerpad_max_install_names CMakeFiles/SimpleTestsCUDA.dir/BlockMatrix.cpp.o CMakeFiles/SimpleTestsCUDA.dir/Matrix.cpp.o ./SimpleTestsCUDA_generated_SimpleTests.cu.o ./SimpleTestsCUDA_generated_BlockMatrix.cu.o -o SimpleTestsCUDA /usr/local/cuda/lib/libcudart.dylib /usr/local/cuda/lib/libcuda.dylib
Which fails with a lot of "file is not of required architecture" warnings from ld. Now if I add manually -m32 to the command above it works. However I have no idea how to teach cmake to add -m32 to every gcc (or ld) invocation. So far it does it for nvcc and gcc, but not for linking..
If you set the env var LDFLAGS before you run cmake on the project it will work as well:
export LDFLAGS=-m32
cmake ../source
see above
set(CMAKE_C_FLAGS -m32)
set(CMAKE_CXX_FLAGS -m32)
Another solution might be to say:
if (Apple)
set (CMAKE_OSX_ARCHITECTURES i386)
set (CUDA_64_BIT_DEVICE_CODE OFF)
endif (Apple)
Hope this helps.