Eclipse 3.7.1 CDT 1.4.1 GCC 4.6.2
This is an example of a piece of C++11 code:
auto text = std::unique_ptr(new char[len]);
I had several issues too (Ubuntu 13.04 64-bit, g++-4.8, eclipse Juno 3.8.1, CDT 6.0.0). A lot of things are mentioned above, sorry to repeat those, but additionally I had problems utilizing
std::thread
as part of c++11 (adding -pthread for the linker solves that issue). Anyway, finally these settings worked fine:
Project -> Properties -> C/C++ Build -> Settings -> Miscellaneous. Add the
-std=c++11
flag for the GCC and G++ compilers. Click Apply.
For the linker, same window, Miscellaneous, Linker flags, added the
-pthread
flag. Shared library settings, Shared object name, add the
-Wl,--no-as-needed
flag too. Click Apply.
C/C++ General -> Paths and symbols -> Symbols TAB, GNU C++ selected, Add the
__GXX_EXPERIMENTAL_CXX0X__
(no value)
flag. Click Apply.
C/C++ General -> Preprocessor Include paths.. -> Providers tab : check
CDT GCC built-in Compiler Settings
and for "Command to get compiler specs", add the
-std=c++11
flag. Uncheck Share. Click Apply.
CDT Managages Build Setting Entries, check this too. Uncheck the two others. Click Apply.
Going back to the Entries tab, GNU C++ CDT Managages Build Setting Entries, you should now see your added
__GXX_EXPERIMENTAL_CXX0X__
entry.
That's it. When coding, typing
std::
can now auto-complete the thread class for instance, builds should work fine and there should be no
std::system_error'what(): Enable multithreading to use std::thread: Operation not permitted
at runtime.
To get support for C++14 in Eclipse Luna, you could do these steps:
C++ General -> Preprocessor Include -> Providers -> CDT Cross GCC Built-in Compiler Settings
, add "-std=c++14"C++ Build -> Settings -> Cross G++ Compiler -> Miscellaneous
, add "-std=c++14"Reindex your project and eventually restart Eclipse. It should work as expected.
I solved it this way on a Mac. I used Homebrew to install the latest version of gcc/g++. They land in /usr/local/bin with includes in /usr/local/include.
I CD'd into /usr/local/bin and made a symlink from g++@7whatever to just g++ cause that @ bit is annoying.
Then I went to MyProject -> Properties -> C/C++ Build -> Settings -> GCC C++ Compiler and changed the command from "g++" to "/usr/local/bin/g++". If you decide not to make the symbolic link, you can be more specific.
Do the same thing for the linker.
Apply and Apply and Close. Let it rebuild the index. For a while, it showed a daunting number of errors, but I think that was while building indexes. While I was figuring out the errors, they all disappeared without further action.
I think without verifying that you could also go into Eclipse -> Properties -> C/C++ -> Core Build Toolchains and edit those with different paths, but I'm not sure what that will do.
Neither the hack nor the cleaner version work for Indigo. The hack is ignored, and the required configuration options are missing. For no apparent reason, build started working after not working and not providing any useful reason why. At least from the command line, I get reproducible results.
For Eclipse CDT Kepler what worked for me to get rid of std::thread
unresolved symbol is:
Go to Preferences->C/C++->Build->Settings
Select the Discovery tab
Select CDT GCC Built-in Compiler Settings [Shared]
Add the -std=c++11 to the "Command to get the compiler specs:" field such as:
${COMMAND} -E -P -v -dD -std=c++11 ${INPUTS}
Adding -std=c++11
to project Properties/C/C++ Build->Settings->Tool Settings->GCC C++ Compiler->Miscellaneous->Other
Flags wasn't enough for Kepler, however it was enough for older versions such as Helios.
When using a cross compiler, I often get advanced custom build systems meticulously crafted by colleagues. I use "Makefile Project with Existing code" so most of the other answers are not applicable.
At the start of the project, I have to specify that I'm using a cross compiler in the wizard for "Makefile Project with Existing Code". The annoying thing is that in the last 10 or so years, the cross compiler button on that wizard doesn't prompt for where the cross compiler is. So in a step that fixes the C++ problem and the cross compiler problem, I have to go to the providers tab as mentioned by answers like @ravwojdyla above, but the provider I have to select is the cross-compiler provider. Then in the command box I put the full path to the compiler and I add -std=gnu++11 for the C++ standard I want to have support for. This works out as well as can be expected.
You can do this to an existing project. The only thing you might need to do is rerun the indexer.
I have never had to add the experimental flag or override __cplusplus's definition. The only thing is, if I have a substantial amount of modern C code, I have nowhere to put the C-specific standard option.
And for when things are going really poorly, getting a parser log, using that command in the Indexer submenu, can be very informative.