-std=c++11 not working (CB12.11)

[taimou]

Hi,
I seem to have a very strange problem with CB12.11
For some reason it won't compile with "-std=c++11" and as for the error it says that no such command can be found:

Code

-------------- Build: default in Lethal_Sp4ce_irr (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe   -std=c++11   -IC:\SDL-1.2.15\include\SDL -IC:\irrlicht-1.8\include -IC:\SDL_mixer-1.2.12  -c D:\git\lethal_sp4ce_master\build\Lethal_Sp4ce_irr\src\ls_audio.cpp -o .objs\src\ls_audio.o
cc1plus.exe: error: unrecognized command line option "-std=c++11"
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)

Any ideas why it's not recognizing the option?

The project compiles fine with DevC++ so no idea what's the problem here.

- taimou

[oBFusCATed]

This is the problem: http://wiki.codeblocks.org/index.php?title=FAQ-General#Q:_What_Code::Blocks_is_not.3F

[taimou]

This is the problem: http://wiki.codeblocks.org/index.php?title=FAQ-General#Q:_What_Code::Blocks_is_not.3F

Yes CB is not a compiler, however DevC++ also uses Mingw32-gcc as the compiler and as I said before the project compiles fine using DevC++ as the IDE.
So one could assume that CB is doing something wrong in directing the -std command to Mingw32-gcc.
Of course I can be completely wrong in this matter too, but then I'm baffled as to what could cause this problem.

//EDIT
Well I managed to fix the problem by changing the compiler CB uses to the one DevC++ uses.
Apparently there was some difference in the compiler versions then, or somesuch.

[Jenna]

Which compiler have you used with C::B ?
TDM's MinGW shipped with C::B 12.11 (gcc 4.7.1) works fine with this option..

[chaoticbob]

Hi,

I know this is and old topic, but I wanted to post this in case someone runs across the same problem.

I ran into the same problem as the OP. Turned out it was exactly what I had suspected. I have several different version of MingW installed on my system. Apparently C::B is very good at finding these different versions. The version that it defaulted me to was my GNUstep MingW using GCC 4.6.1. I just changed the Compiler's installation directory in Settings->Compiler to C:\Program Files (x86)\CodeBlocks\MinGW and it fixed the problem. Obviously, this applies to GNU GCC Compiler on the drop down.

Hope it helps and happy coding.

[scarphin]

Not directly related but I think cb doesn't like the '=' sign in 'project->build options->compiler settings->other options'. When I try to enter '-std=c++11' on a newline, it doesn't save nor use that setting. If I add it to another line like '-fexceptions -std=c++11' (all in one line), it works but I don't think that's the intended syntax here. And lastly if I manually edit the project file and add a new entry for '-std=c++11' it works but it's still not shown in 'project->build options->compiler settings->other options' even though it works. Am I missing something here or is it the '='?

[Jenna]

It should go (automatically) into "Compiler flags".

[scarphin]

It should go (automatically) into "Compiler flags".

I checked but it didn't go into compiler flags too.

Win7 x64 cb12.11

[stahta01]

It should go (automatically) into "Compiler flags".

That does NOT work on Windows 7 32 Bit using 12.11 or self built SVN 8991.

What it does is remove from other options any thing that can be used in "Compiler flags" flags section.

Tim S.

[Alpha]

Is there a bug here that needs solving?  Or is this just a configuration problem?

[stahta01]

Is there a bug here that needs solving?  Or is this just a configuration problem?

It has always worked this way for me; no idea what configuration setting to check.
Does it work for you on Windows?

Tim S.

[scarphin]

Is there a bug here that needs solving?  Or is this just a configuration problem?

'-std=c++11' entry isn't saved in 'other options' nor it goes into 'compiler flags' and in the end it's not inserted into the resulting command string so I think that's not the intended behavior.

[MortenMacFly]

It should go (automatically) into "Compiler flags".

Are you sure? IMHO the philosophy is/was as follows:

If a user provided a compiler flag that is present in the checkable list of compiler switches to "other options", then we are in trouble: Checkable list defines the switch as "off", other options as "on". In that case the checkable compiler switches over-rule the other options.

So to make it simple: Never put options that are available in the checkable list of compiler switches (the check-boxes) into other options. This is by design.

[osdt]

It should go (automatically) into "Compiler flags".

Are you sure? IMHO the philosophy is/was as follows:

If a user provided a compiler flag that is present in the checkable list of compiler switches to "other options", then we are in trouble: Checkable list defines the switch as "off", other options as "on". In that case the checkable compiler switches over-rule the other options.

So to make it simple: Never put options that are available in the checkable list of compiler switches (the check-boxes) into other options. This is by design.

I'm using CB for at least two years now and never noticed [1] this 'feature'. If CB silently removes '-Wall' from 'other options' and does not turn on the checkable switch at the same time, it's definitely a bug by design!
What if '-fexceptions' becomes a checkable switch some day?

@ devs: please never modify user-specified values silently, ask for it beforehand

- osdt

[1] most likely because I use one line for related options ... '-Wall -Wextra ...'

[MortenMacFly]

If CB silently removes '-Wall' from 'other options' and does not turn on the checkable switch at the same time, it's definitely a bug by design!

What if '-fexceptions' becomes a checkable switch some day?

No problem: At runtime, when you load a project file its managed correctly as the options are being sorted into the appropriate settings. So, if we decide to change an option (i.e. move it to "default") its no problem after you updated C::B and re-opening the project file.

In a single run, however, there is no way to find out what you mean when you tell the compiler on one setting page to enable and on the other to disable an option. What ever magic we do here is wrong in 50% of the cases. How would you decide in such a case?

Thus we decided to for for it the way it is now. In addition its more intuitive as most user search the default options in the first place.

The only fail-save way I see is to disable the check-boxes completely and force the user to enter all these flags on one page only. Hence especially newbies will cry then and never learn what a compiler can do for you. So in the end: Its not an option.