Related
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<char[]>(new char[len]);
The Eclipse editor complains about:
Function 'unique_ptr' could not be resolved
The Makefile compilation works fine. How to make Eclipse stop complaining about these sort of errors?
I found this article in the Eclipse forum, just followed those steps and it works for me. I am using Eclipse Indigo 20110615-0604 on Windows with a Cygwin setup.
Make a new C++ project
Default options for everything
Once created, right-click the project and go to "Properties"
C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Miscellaneous -> Other Flags. Put -std=c++0x (or for newer compiler version -std=c++11 at the end . ... instead of GCC C++ Compiler I have also Cygwin compiler
C/C++ General -> Paths and Symbols -> Symbols -> GNU C++. Click "Add..." and paste __GXX_EXPERIMENTAL_CXX0X__ (ensure to append and prepend two underscores) into "Name" and leave "Value" blank.
Hit Apply, do whatever it asks you to do, then hit OK.
There is a description of this in the Eclipse FAQ now as well: Eclipse FAQ/C++11 Features.
Eclipse setting
Instruction For Eclipse CDT 4.4 Luna and 4.5 Mars
First, before creating project, configure Eclipse syntax parser:
Window -> Preferences -> C/C++ -> Build -> Settings -> Discovery -> CDT GCC Build-in Compiler Settings
in the text box entitled Command to get compiler specs append -std=c++11
Now you can create project, configuration depends on what kind of project you created:
For project created as: File -> New -> Project -> C/C++ -> C++ Project
Right click on created project and open
Properties -> C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Dialect
Put -std=c++11 into text box entitled other dialect flags or select ISO C++11 from the Language standard drop down.
For CMake project
Generate eclipse project files (inside your project)
mkdir build
cd build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ..
Then import generated directory to eclipse as standard eclipse project. Right click project and open
Properties -> C/C++ General -> Preprocessor Include Paths, Marcos etc. -> Providers
enable CDT GCC Build-in Compiler Settings and move it higher than Contributed PathEntry Containers (This is important)
Last Common Step
recompile, regenerate Project ->C/C++ Index and restart Eclipse.
Update 2016:
As of gcc 6 (changes), the default C++ dialect is C++14. That means that unless you explicitly need a newer or older dialect than than, you don't need to do anything with eclipse anymore.
For Luna and Mars
This community wiki section incorporates the answer by Trismegistos;
1. Before creating project, configure Eclipse syntax parser:
Window -> Preferences -> C/C++ -> Build -> Settings -> Discovery -> CDT GCC Build-in Compiler Settings
in the text box entitled Command to get compiler specs append -std=c++14
2. Create project, configuration depends on what kind of project you created:
For project created as: File -> New -> Project -> C/C++ -> C++ Project
Right click on created project and open
Properties -> C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Dialect
Put -std=c++14 into text box entitled other dialect flags or select ISO C++11 from the Language standard drop down.
There's now a new way to solve this without the GXX_EXPERIMENTAL hack.
For most recent versions: (Currently Juno and Kepler Luna):
Under newer versions of Juno the settings are located at Project properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> tab Providers -> CDT GCC Builtin Compiler Settings ().
Older versions 2012/2013:
Under C/C++ Build (at project settings), find the Preprocessor Include Path and go to the Providers Tab. Deselect all except CDT GCC Builtin Compiler Settings. Then untag Share settings entries … . Add the option -std=c++11 to the text box called Command to get compiler specs.
Go to paths and symbols. Under Symbols, click restore defaults, and then apply.
Notes:
Eclipse is picky about hitting apply, you need to do it every time you leave a settings tab.
[Self-promotion]: I wrote my own more detailed instructions based on the above.
http://scrupulousabstractions.tumblr.com/post/36441490955/eclipse-mingw-builds
Thanks to the user Nobody at https://stackoverflow.com/a/13635080/1149664
For the latest (Juno) eclipse cdt the following worked for me, no need to declare __GXX_EXPERIMENTAL_CXX0X__ on myself. This works for the the CDT indexer and as parameter for the compiler:
"your project name" -> right click -> properties:
C/C++ General -> Preprocessor Include Paths, Macros etc. -> switch to the tab named "Providers":
for "Configuration" select "Release" (and afterwards "debug")
switch off all providers and just select "CDT GCC Built-in Compiler Settings"
uncheck "Share setting entries between projects (global provider)"
in the "Command to get compiler specs:" add "-std=c++11" without the quotes (may work with quotes too)
hit apply and close the options
rebuild the index
Now all the c++11 related stuff should be resolved correctly by the indexer.
win7 x64, latest official eclipse with cdt
mingw-w64 gcc 4.7.2 from the mingwbuilds project on sourceforge
I had the same problem on my Eclipse Juno. These steps solved the problem :
Go to Project -> Properties -> C/C++ General -> Path and Symbols -> Tab [Symbols].
Add the symbol : __cplusplus with the value 201103L
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}
Ok and Rebuild Index for the project.
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.
I can't yet comment so am writing my own answer:
It's related to __GXX_EXPERIMENTAL_CXX0X__ and it's valid for Eclipse Juno and CDT 8.x.
Some parts of this answer are already covered in other answers but I want it to be coherent.
To make it possible to build using stdc++11, one have to add specific flag for compiler. You can do that via project properties. To modify project properties RMB andProject properties or ALT + ENTER. Then C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Miscellaneous -> Other Flags. Put -std=c++11 at the end of line, for GCC it will look something like: -c -fmessage-length=0 -std=c++11. By adding -stdc++11 flag compiler (GCC) will declare __GXX_EXPERIMENTAL_CXX0X__ by itself.
At this point you can build project using all the goodness of C++11.
The problem is that Eclipse has it's own parser to check for errors - that's why you're still getting all the nasty errors in Eclipse editor, while at the same time you can build and run project without any. There is a way to solve this problem by explicitly declaring __GXX_EXPERIMENTAL_CXX0X__ flag for the project, one can do that (just like Carsten Greiner said):
C/C++ General -> Paths and Symbols -> Symbols -> GNU C++. Click "Add..." and past __GXX_EXPERIMENTAL_CXX0X__ (ensure to append and prepend two underscores) into "Name" and leave "Value" blank.
And now is the extra part I wanted to cover in comment to the first answer, go to:
C/C++ General -> Preprocessor Include Path Macros etc. -> Providers, and Select CDT Managed Build Setting Entries then click APPLY and go back to Entries tab, under GNU C++ there should be now CDT Managed Build Setting Entries check if inside there is defined __GXX_EXPERIMENTAL_CXX0X__ if it is -> APPLY and rebuild index you should be fine at this point.
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.
I don't know if it is only me, the highest ranked solution doesn't work for me, my eclipse version is just normal eclipse platform installed by using sudo apt-get install eclipse in Ubuntu
But I found a solution which adopts method together from both the highest ranked solution and the second, what I did to make it work is described as below (Note that the other steps like creating a C++ project etc. is ignored for simplicity)
Once you have created the C++ project
(1) C/C++ General -> Paths and Symbols -> Symbols -> GNU C++. Click "Add..." and paste GXX_EXPERIMENTAL_CXX0X (ensure to append and prepend two underscores) into "Name" and leave "Value" blank.
(2) Under C/C++ Build (at project settings), find the Preprocessor Include Path and go to the Providers Tab. Deselect all except CDT GCC Builtin Compiler Settings. Then untag Share settings entries … . Add the option -std=c++11 to the text box called Command to get compiler specs
After performed above 2 and 2 only steps, it works, the eclipse is able to resolve the unique_ptr, I don't know why this solution works, hope that it can help people.
Eclipse C/C++ does not recognize the symbol std::unique_ptr even though you have included the C++11 memory header in your file.
Assuming you are using the GNU C++ compiler, this is what I did to fix:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths -> GNU C++ -> CDT User Setting Entries
Click on the "Add..." button
Select "Preprocessor Macro" from the dropdown menu
Name: __cplusplus Value: 201103L
Hit Apply, and then OK to go back to your project
Then rebuild you C++ index: Projects -> C/C++ Index -> Rebuild
For me on Eclipse Neon I followed Trismegistos answer here above , YET I also added an additional step:
Go to project --> Properties --> C++ General --> Preprocessor Include paths,Macros etc. --> Providers --> CDT Cross GCC Built-in Compiler Settings, append the flag "-std=c++11"
Hit apply and OK.
Cheers,
Guy.
right-click the project and go to "Properties"
C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Miscellaneous -> Other Flags. Put -lm at the end of other flags text box and OK.
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.
To get support for C++14 in Eclipse Luna, you could do these steps:
In C++ General -> Preprocessor Include -> Providers -> CDT Cross GCC Built-in Compiler Settings, add "-std=c++14"
In 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.
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.
I had a similar problem using Eclipse C++ 2019-03 for a mixed C and C++ project that used std::optional and std::swap. What worked for me was this.
In the project
Properties->C/C++ Build->Settings->Tool Settings->Cross G++ Compiler, remove -std=gnu++17 from Miscellaneous and put it in Dialect->Other Dialect Flags instead.
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<char[]>(new char[len]);
The Eclipse editor complains about:
Function 'unique_ptr' could not be resolved
The Makefile compilation works fine. How to make Eclipse stop complaining about these sort of errors?
I found this article in the Eclipse forum, just followed those steps and it works for me. I am using Eclipse Indigo 20110615-0604 on Windows with a Cygwin setup.
Make a new C++ project
Default options for everything
Once created, right-click the project and go to "Properties"
C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Miscellaneous -> Other Flags. Put -std=c++0x (or for newer compiler version -std=c++11 at the end . ... instead of GCC C++ Compiler I have also Cygwin compiler
C/C++ General -> Paths and Symbols -> Symbols -> GNU C++. Click "Add..." and paste __GXX_EXPERIMENTAL_CXX0X__ (ensure to append and prepend two underscores) into "Name" and leave "Value" blank.
Hit Apply, do whatever it asks you to do, then hit OK.
There is a description of this in the Eclipse FAQ now as well: Eclipse FAQ/C++11 Features.
Eclipse setting
Instruction For Eclipse CDT 4.4 Luna and 4.5 Mars
First, before creating project, configure Eclipse syntax parser:
Window -> Preferences -> C/C++ -> Build -> Settings -> Discovery -> CDT GCC Build-in Compiler Settings
in the text box entitled Command to get compiler specs append -std=c++11
Now you can create project, configuration depends on what kind of project you created:
For project created as: File -> New -> Project -> C/C++ -> C++ Project
Right click on created project and open
Properties -> C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Dialect
Put -std=c++11 into text box entitled other dialect flags or select ISO C++11 from the Language standard drop down.
For CMake project
Generate eclipse project files (inside your project)
mkdir build
cd build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ..
Then import generated directory to eclipse as standard eclipse project. Right click project and open
Properties -> C/C++ General -> Preprocessor Include Paths, Marcos etc. -> Providers
enable CDT GCC Build-in Compiler Settings and move it higher than Contributed PathEntry Containers (This is important)
Last Common Step
recompile, regenerate Project ->C/C++ Index and restart Eclipse.
Update 2016:
As of gcc 6 (changes), the default C++ dialect is C++14. That means that unless you explicitly need a newer or older dialect than than, you don't need to do anything with eclipse anymore.
For Luna and Mars
This community wiki section incorporates the answer by Trismegistos;
1. Before creating project, configure Eclipse syntax parser:
Window -> Preferences -> C/C++ -> Build -> Settings -> Discovery -> CDT GCC Build-in Compiler Settings
in the text box entitled Command to get compiler specs append -std=c++14
2. Create project, configuration depends on what kind of project you created:
For project created as: File -> New -> Project -> C/C++ -> C++ Project
Right click on created project and open
Properties -> C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Dialect
Put -std=c++14 into text box entitled other dialect flags or select ISO C++11 from the Language standard drop down.
There's now a new way to solve this without the GXX_EXPERIMENTAL hack.
For most recent versions: (Currently Juno and Kepler Luna):
Under newer versions of Juno the settings are located at Project properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> tab Providers -> CDT GCC Builtin Compiler Settings ().
Older versions 2012/2013:
Under C/C++ Build (at project settings), find the Preprocessor Include Path and go to the Providers Tab. Deselect all except CDT GCC Builtin Compiler Settings. Then untag Share settings entries … . Add the option -std=c++11 to the text box called Command to get compiler specs.
Go to paths and symbols. Under Symbols, click restore defaults, and then apply.
Notes:
Eclipse is picky about hitting apply, you need to do it every time you leave a settings tab.
[Self-promotion]: I wrote my own more detailed instructions based on the above.
http://scrupulousabstractions.tumblr.com/post/36441490955/eclipse-mingw-builds
Thanks to the user Nobody at https://stackoverflow.com/a/13635080/1149664
For the latest (Juno) eclipse cdt the following worked for me, no need to declare __GXX_EXPERIMENTAL_CXX0X__ on myself. This works for the the CDT indexer and as parameter for the compiler:
"your project name" -> right click -> properties:
C/C++ General -> Preprocessor Include Paths, Macros etc. -> switch to the tab named "Providers":
for "Configuration" select "Release" (and afterwards "debug")
switch off all providers and just select "CDT GCC Built-in Compiler Settings"
uncheck "Share setting entries between projects (global provider)"
in the "Command to get compiler specs:" add "-std=c++11" without the quotes (may work with quotes too)
hit apply and close the options
rebuild the index
Now all the c++11 related stuff should be resolved correctly by the indexer.
win7 x64, latest official eclipse with cdt
mingw-w64 gcc 4.7.2 from the mingwbuilds project on sourceforge
I had the same problem on my Eclipse Juno. These steps solved the problem :
Go to Project -> Properties -> C/C++ General -> Path and Symbols -> Tab [Symbols].
Add the symbol : __cplusplus with the value 201103L
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}
Ok and Rebuild Index for the project.
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.
I can't yet comment so am writing my own answer:
It's related to __GXX_EXPERIMENTAL_CXX0X__ and it's valid for Eclipse Juno and CDT 8.x.
Some parts of this answer are already covered in other answers but I want it to be coherent.
To make it possible to build using stdc++11, one have to add specific flag for compiler. You can do that via project properties. To modify project properties RMB andProject properties or ALT + ENTER. Then C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Miscellaneous -> Other Flags. Put -std=c++11 at the end of line, for GCC it will look something like: -c -fmessage-length=0 -std=c++11. By adding -stdc++11 flag compiler (GCC) will declare __GXX_EXPERIMENTAL_CXX0X__ by itself.
At this point you can build project using all the goodness of C++11.
The problem is that Eclipse has it's own parser to check for errors - that's why you're still getting all the nasty errors in Eclipse editor, while at the same time you can build and run project without any. There is a way to solve this problem by explicitly declaring __GXX_EXPERIMENTAL_CXX0X__ flag for the project, one can do that (just like Carsten Greiner said):
C/C++ General -> Paths and Symbols -> Symbols -> GNU C++. Click "Add..." and past __GXX_EXPERIMENTAL_CXX0X__ (ensure to append and prepend two underscores) into "Name" and leave "Value" blank.
And now is the extra part I wanted to cover in comment to the first answer, go to:
C/C++ General -> Preprocessor Include Path Macros etc. -> Providers, and Select CDT Managed Build Setting Entries then click APPLY and go back to Entries tab, under GNU C++ there should be now CDT Managed Build Setting Entries check if inside there is defined __GXX_EXPERIMENTAL_CXX0X__ if it is -> APPLY and rebuild index you should be fine at this point.
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.
I don't know if it is only me, the highest ranked solution doesn't work for me, my eclipse version is just normal eclipse platform installed by using sudo apt-get install eclipse in Ubuntu
But I found a solution which adopts method together from both the highest ranked solution and the second, what I did to make it work is described as below (Note that the other steps like creating a C++ project etc. is ignored for simplicity)
Once you have created the C++ project
(1) C/C++ General -> Paths and Symbols -> Symbols -> GNU C++. Click "Add..." and paste GXX_EXPERIMENTAL_CXX0X (ensure to append and prepend two underscores) into "Name" and leave "Value" blank.
(2) Under C/C++ Build (at project settings), find the Preprocessor Include Path and go to the Providers Tab. Deselect all except CDT GCC Builtin Compiler Settings. Then untag Share settings entries … . Add the option -std=c++11 to the text box called Command to get compiler specs
After performed above 2 and 2 only steps, it works, the eclipse is able to resolve the unique_ptr, I don't know why this solution works, hope that it can help people.
Eclipse C/C++ does not recognize the symbol std::unique_ptr even though you have included the C++11 memory header in your file.
Assuming you are using the GNU C++ compiler, this is what I did to fix:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths -> GNU C++ -> CDT User Setting Entries
Click on the "Add..." button
Select "Preprocessor Macro" from the dropdown menu
Name: __cplusplus Value: 201103L
Hit Apply, and then OK to go back to your project
Then rebuild you C++ index: Projects -> C/C++ Index -> Rebuild
For me on Eclipse Neon I followed Trismegistos answer here above , YET I also added an additional step:
Go to project --> Properties --> C++ General --> Preprocessor Include paths,Macros etc. --> Providers --> CDT Cross GCC Built-in Compiler Settings, append the flag "-std=c++11"
Hit apply and OK.
Cheers,
Guy.
right-click the project and go to "Properties"
C/C++ Build -> Settings -> Tool Settings -> GCC C++ Compiler -> Miscellaneous -> Other Flags. Put -lm at the end of other flags text box and OK.
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.
To get support for C++14 in Eclipse Luna, you could do these steps:
In C++ General -> Preprocessor Include -> Providers -> CDT Cross GCC Built-in Compiler Settings, add "-std=c++14"
In 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.
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.
I had a similar problem using Eclipse C++ 2019-03 for a mixed C and C++ project that used std::optional and std::swap. What worked for me was this.
In the project
Properties->C/C++ Build->Settings->Tool Settings->Cross G++ Compiler, remove -std=gnu++17 from Miscellaneous and put it in Dialect->Other Dialect Flags instead.
The error is as above. I have what should be all the necessary files include in the eclipse project:
/usr/include/c++/4.6
/usr/include
/usr/include/linux
/usr/local/include
etc.
I tried std::cout and using namespace std; cout but it still says unresolved.
I have imported iostream and cstdlib.
Also, I'm on Ubuntu 12.04 with eclipse 3.7.2.
Code snippet:
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include "XPLMDisplay.h"
#include "XPLMGraphics.h"
int XPluginStart(char * outName, char * outSig, char * outDesc) {
/* ... */
std::cout << "test" << std::endl;
/* ... */
}
using namespace std;
UPDATE: I had created the eclipse project from existing code. Creating a new c++ project fixes it. I'll accept an answer that explains what setting in the existing project could cause this (so I don't have to cut & paste all my projects).
Most likely you have some system-specific include directories missing in your settings which makes it impossible for indexer to correctly parse iostream, thus the errors. Selecting Index -> Search For Unresolved Includes in the context menu of the project will give you the list of unresolved includes which you can search in /usr/include and add containing directories to C++ Include Paths and Symbols in Project Properties.
On my system I had to add /usr/include/c++/4.6/x86_64-linux-gnu for bits/c++config.h to be resolved and a few more directories.
Don't forget to rebuild the index (Index -> Rebuild) after adding include directories.
To get rid of symbol warnings you don't want, first you should understand how Eclipse CDT normally comes up with unknown symbol warnings in the first place. This is its process, more or less:
Eclipse detects the GCC toolchains available on the system
Your Eclipse project is configured to use a particular toolchain
Eclipse does discovery on the toolchain to find its include paths and built-in defines, i.e. by running it with relevant options and reading the output
Eclipse reads the header files from the include paths
Eclipse indexes the source code in your project
Eclipse shows warnings about unresolved symbols in the editor
It might be better in the long run to fix problems with the earlier steps rather than to override their results by manually adding include directories, symbols, etc.
Toolchains
If you have GCC installed, and Eclipse has detected it, it should list that GCC as a toolchain choice that a new C++ project could use, which will also show up in Window -> Preferences -> C/C++ -> New CDT Project Wizard on the Preferred Toolchains tab's Toolchains box on the right side. If it's not showing up, see the CDT FAQ's answer about compilers that need special environments (as well as MinGW and Cygwin answers for the Windows folk.)
If you have an existing Eclipse C++ project, you can change the associated toolchain by opening the project properties, and going to C/C++ Build -> Tool Chain Editor and choosing the toolchain you want from the Current toolchain: pulldown. (You'll have to uncheck the Display compatible toolchains only box first if the toolchain you want is different enough from the one that was previously set in the project.)
If you added a toolchain to the system after launching Eclipse, you will need to restart it for it to detect the toolchain.
Discovery
Then, if the project's C/C++ Build -> Discovery Options -> Discovery profiles scope is set to Per Language, during the next build the new toolchain associated with the project will be used for auto-discovery of include paths and symbols, and will be used to update the "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols in the Includes and Symbols tabs.
Indexing
Sometimes you need to re-index again after setting the toolchain and doing a build to get the old symbol warnings to go away; right-click on the project folder and go to Index -> Rebuild to do it.
(tested with Eclipse 3.7.2 / CDT 8)
Thanks loads for the answers above. I'm adding an answer for a specific use-case...
On a project with two target architectures each with its own build configuration (the main target is an embedded AVR platform; the second target is my local Linux PC for running unit tests) I found it necessary to set Preferences -> C/C++ -> Indexer -> Use active build configuration as well as to add /usr/include/c++/4.7, /usr/include and /usr/include/c++/4.7/x86_64-linux-gnu to Project Properties -> C/C++ General -> Paths and Symbols and then to rebuild the index.
I tried the marked solution here first. It worked but it is kind hacky, and you need to redo it every time you update the gcc. I finally find a better solution by doing the followings:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc.
Providers -> CDT GCC built-in compiler settings
Uncheck Use global provider shared between projects (you can also modify the global provider if it fits your need)
In Command to get compiler specs, add -std=c++11 at the end
Index->Rebuild
Voila, easy and simple. Hopefully this helps.
Note: I am on Kepler. I am not sure if this works on earlier Eclipse.
I am using Ubuntu 12.04 / Eclipse 4.2.1 / CDT 8.1.1 and I used to have the same problem for quite some time: importing a C++ project from SVN would cause these annoying "Unresolved inclusion" errors and I would instead have to create a new project and copy the files in there as a work-around (still partial, since SVN functionality would not be there!).
At last, I have just found a simple, satisfactory solution:
Go to Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers and check Enable language settings providers for this project.
Restart Eclipse.
Hopefully that already does the trick.
I had a similar problem with *std::shared_ptr* with Eclipse using MinGW and gcc 4.8.1. No matter what, Eclipse would not resolve *shared_ptr*. To fix this, I manually added the __cplusplus macro to the C++ symbols and - viola! - Eclipse can find it. Since I specified -std=c++11 as a compile option, I (ahem) assumed that the Eclipse code analyzer would use that option as well. So, to fix this:
Project Context -> C/C++ General -> Paths and Symbols -> Symbols Tab
Select C++ in the Languages panel.
Add symbol __cplusplus with a value of 201103.
The only problem with this is that gcc will complain that the symbol is already defined(!) but the compile will complete as before.
For me it helped to enable the automated discovery in Properties -> C/C++-Build -> Discovery Options to resolve this problem.
I simply delete all error in the buttom: problem list.
then close project
and reopen project
clean project
build all
run
then those stupids errors go.
If all else fails, like it did in my case, then just disable annotations. I started a c++11 project with own makefile but couldn't fix all the problems. Even if you disable annotations, eclipse will still be able to help you do some autocompletion. Most importantly, the debugger still works!
I had the same issue using Eclipse CDT (Kepler) on Windows with Cygwin installed. After pointing the project properties at every Cygwin include I could think of, it still couldn't find cout.
The final missing piece turned out to be C:cygwin64\lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include.
To sum up:
Right click on the project
Choose Properties
Navigate to C/C++ General > Paths and Symbols > Includes tab
Click Add...
Click File system...
Browse to the location of your Cygwin lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include
Click OK
Here is what my project includes ended up looking like when it was all said and done:
You guys are looking under the wrong section.
I realized the difference when I installed in Linux after recently getting frustrated with Windows and the difference was immediately apparent.
In the new setup I have an includes folder in a projected that I created out of existing source. I can expand this and see a ton of includes; however, I cannot add to them.
This lead me to a hunt for where these files were being listed.
They're listed under the Project Properties > C/C++ General > Preprocessor Includes > GNU C++
CDT GCC Built-in Compiler Settings [Shared]
Under that is a ton of includes.
These settings are set by the toolchain you've selected.
I have created the Makefile project using cmake on Ubuntu 16.04.
When created the eclipse project for the Makefiles which cmake generated I created the new project like so:
File --> new --> Makefile project with existing code.
Only after couple of times doing that I have noticed that the default setting for the "Toolchain for indexer settings" is none.
In my case I have changed it to Linux GCC and all the errors disappeared.
Hope it helps and let me know if it is not a legit solution.
Cheers,
Guy.
I had this happen after updating gcc and eclipse on ArchLinux. What solved it for me was Project -> C/C++ Index -> Rebuild.
Just adding yet another bit of advice after trying a bunch of stuff myself and it not working....
I had GCC installed and the path to the includes set correctly. Had the std error as well, and couldn't get anything working for cout (and I suspect anything in the SL...)
Took me awhile to realize that g++ wasn't installed - gcc was but not g++. So just do:
sudo apt-get install g++
Restart eclipse. Assuming above mentioned details about gcc & paths to includes are fine, you should be okay now...
mine was bit easy to fig out right click >run as>run configration
check boxes include system lib,inherited mains
The error is as above. I have what should be all the necessary files include in the eclipse project:
/usr/include/c++/4.6
/usr/include
/usr/include/linux
/usr/local/include
etc.
I tried std::cout and using namespace std; cout but it still says unresolved.
I have imported iostream and cstdlib.
Also, I'm on Ubuntu 12.04 with eclipse 3.7.2.
Code snippet:
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include "XPLMDisplay.h"
#include "XPLMGraphics.h"
int XPluginStart(char * outName, char * outSig, char * outDesc) {
/* ... */
std::cout << "test" << std::endl;
/* ... */
}
using namespace std;
UPDATE: I had created the eclipse project from existing code. Creating a new c++ project fixes it. I'll accept an answer that explains what setting in the existing project could cause this (so I don't have to cut & paste all my projects).
Most likely you have some system-specific include directories missing in your settings which makes it impossible for indexer to correctly parse iostream, thus the errors. Selecting Index -> Search For Unresolved Includes in the context menu of the project will give you the list of unresolved includes which you can search in /usr/include and add containing directories to C++ Include Paths and Symbols in Project Properties.
On my system I had to add /usr/include/c++/4.6/x86_64-linux-gnu for bits/c++config.h to be resolved and a few more directories.
Don't forget to rebuild the index (Index -> Rebuild) after adding include directories.
To get rid of symbol warnings you don't want, first you should understand how Eclipse CDT normally comes up with unknown symbol warnings in the first place. This is its process, more or less:
Eclipse detects the GCC toolchains available on the system
Your Eclipse project is configured to use a particular toolchain
Eclipse does discovery on the toolchain to find its include paths and built-in defines, i.e. by running it with relevant options and reading the output
Eclipse reads the header files from the include paths
Eclipse indexes the source code in your project
Eclipse shows warnings about unresolved symbols in the editor
It might be better in the long run to fix problems with the earlier steps rather than to override their results by manually adding include directories, symbols, etc.
Toolchains
If you have GCC installed, and Eclipse has detected it, it should list that GCC as a toolchain choice that a new C++ project could use, which will also show up in Window -> Preferences -> C/C++ -> New CDT Project Wizard on the Preferred Toolchains tab's Toolchains box on the right side. If it's not showing up, see the CDT FAQ's answer about compilers that need special environments (as well as MinGW and Cygwin answers for the Windows folk.)
If you have an existing Eclipse C++ project, you can change the associated toolchain by opening the project properties, and going to C/C++ Build -> Tool Chain Editor and choosing the toolchain you want from the Current toolchain: pulldown. (You'll have to uncheck the Display compatible toolchains only box first if the toolchain you want is different enough from the one that was previously set in the project.)
If you added a toolchain to the system after launching Eclipse, you will need to restart it for it to detect the toolchain.
Discovery
Then, if the project's C/C++ Build -> Discovery Options -> Discovery profiles scope is set to Per Language, during the next build the new toolchain associated with the project will be used for auto-discovery of include paths and symbols, and will be used to update the "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols in the Includes and Symbols tabs.
Indexing
Sometimes you need to re-index again after setting the toolchain and doing a build to get the old symbol warnings to go away; right-click on the project folder and go to Index -> Rebuild to do it.
(tested with Eclipse 3.7.2 / CDT 8)
Thanks loads for the answers above. I'm adding an answer for a specific use-case...
On a project with two target architectures each with its own build configuration (the main target is an embedded AVR platform; the second target is my local Linux PC for running unit tests) I found it necessary to set Preferences -> C/C++ -> Indexer -> Use active build configuration as well as to add /usr/include/c++/4.7, /usr/include and /usr/include/c++/4.7/x86_64-linux-gnu to Project Properties -> C/C++ General -> Paths and Symbols and then to rebuild the index.
I tried the marked solution here first. It worked but it is kind hacky, and you need to redo it every time you update the gcc. I finally find a better solution by doing the followings:
Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros, etc.
Providers -> CDT GCC built-in compiler settings
Uncheck Use global provider shared between projects (you can also modify the global provider if it fits your need)
In Command to get compiler specs, add -std=c++11 at the end
Index->Rebuild
Voila, easy and simple. Hopefully this helps.
Note: I am on Kepler. I am not sure if this works on earlier Eclipse.
I am using Ubuntu 12.04 / Eclipse 4.2.1 / CDT 8.1.1 and I used to have the same problem for quite some time: importing a C++ project from SVN would cause these annoying "Unresolved inclusion" errors and I would instead have to create a new project and copy the files in there as a work-around (still partial, since SVN functionality would not be there!).
At last, I have just found a simple, satisfactory solution:
Go to Project -> Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers and check Enable language settings providers for this project.
Restart Eclipse.
Hopefully that already does the trick.
I had a similar problem with *std::shared_ptr* with Eclipse using MinGW and gcc 4.8.1. No matter what, Eclipse would not resolve *shared_ptr*. To fix this, I manually added the __cplusplus macro to the C++ symbols and - viola! - Eclipse can find it. Since I specified -std=c++11 as a compile option, I (ahem) assumed that the Eclipse code analyzer would use that option as well. So, to fix this:
Project Context -> C/C++ General -> Paths and Symbols -> Symbols Tab
Select C++ in the Languages panel.
Add symbol __cplusplus with a value of 201103.
The only problem with this is that gcc will complain that the symbol is already defined(!) but the compile will complete as before.
For me it helped to enable the automated discovery in Properties -> C/C++-Build -> Discovery Options to resolve this problem.
I simply delete all error in the buttom: problem list.
then close project
and reopen project
clean project
build all
run
then those stupids errors go.
If all else fails, like it did in my case, then just disable annotations. I started a c++11 project with own makefile but couldn't fix all the problems. Even if you disable annotations, eclipse will still be able to help you do some autocompletion. Most importantly, the debugger still works!
I had the same issue using Eclipse CDT (Kepler) on Windows with Cygwin installed. After pointing the project properties at every Cygwin include I could think of, it still couldn't find cout.
The final missing piece turned out to be C:cygwin64\lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include.
To sum up:
Right click on the project
Choose Properties
Navigate to C/C++ General > Paths and Symbols > Includes tab
Click Add...
Click File system...
Browse to the location of your Cygwin lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include
Click OK
Here is what my project includes ended up looking like when it was all said and done:
You guys are looking under the wrong section.
I realized the difference when I installed in Linux after recently getting frustrated with Windows and the difference was immediately apparent.
In the new setup I have an includes folder in a projected that I created out of existing source. I can expand this and see a ton of includes; however, I cannot add to them.
This lead me to a hunt for where these files were being listed.
They're listed under the Project Properties > C/C++ General > Preprocessor Includes > GNU C++
CDT GCC Built-in Compiler Settings [Shared]
Under that is a ton of includes.
These settings are set by the toolchain you've selected.
I have created the Makefile project using cmake on Ubuntu 16.04.
When created the eclipse project for the Makefiles which cmake generated I created the new project like so:
File --> new --> Makefile project with existing code.
Only after couple of times doing that I have noticed that the default setting for the "Toolchain for indexer settings" is none.
In my case I have changed it to Linux GCC and all the errors disappeared.
Hope it helps and let me know if it is not a legit solution.
Cheers,
Guy.
I had this happen after updating gcc and eclipse on ArchLinux. What solved it for me was Project -> C/C++ Index -> Rebuild.
Just adding yet another bit of advice after trying a bunch of stuff myself and it not working....
I had GCC installed and the path to the includes set correctly. Had the std error as well, and couldn't get anything working for cout (and I suspect anything in the SL...)
Took me awhile to realize that g++ wasn't installed - gcc was but not g++. So just do:
sudo apt-get install g++
Restart eclipse. Assuming above mentioned details about gcc & paths to includes are fine, you should be okay now...
mine was bit easy to fig out right click >run as>run configration
check boxes include system lib,inherited mains
I have locally forked (via hg clone) a C/C++ (Eclipse CDT) project and imported it into my Eclipse workspace. My editor window for the forked project now looks like this:
Clearly, these are not real errors, since the code builds correctly. Also, these errors are not marked in the original project from which this one was forked.
Why does Eclipse think there are errors in this source?
EDIT: Eclipse error messages when hovering over the "bugs" are, e.g., Type int64_t could not be resolved and symbol 'cout' could not be resolved.
EDIT: I've noticed that Eclipse usually shows a "folder" named includes in the project. It is missing for this project. How can I get it back?
Eclipse has to know the paths where to find the include files. This may be set using general eclipse settings or project by project.
For some reason it seems like the default paths are not set for your current project.
What you can do:
Open the project settings and go to C/C++ General -> Paths and Symbols (at least that is how it is called in my eclipse version) and fix the include directories.
Maybe it is enough to load the default configuration for that specific project. Maybe you have to set up your include pathes by yourself. On Unix / OS X this should usually be usr/include. On Windows I have no idea, but that should be easy to find out.
Afterwards it may be necessary that your rebuild your eclipse index (right click on your project, then index -> rebuild).
If that does not help please share a screenshot of the Paths and Symbols dialog of your project.
Also see the eclipse documentation on this topic.
I had to include
CDT Cross GCC Built-in Compiler Settings
CDT GCC Built in Compiler Settings [ Shared ]
in Properties for the project -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers
add this define in Eclipse to Project Properties->C/C++ General->Paths and Symbols
__STDC_FORMAT_MACROS
Rebuild your eclipse index. It will work.
This worked on Mac OS X Yosemite 10.10.5, Eclipse version Mars.1 Release (4.5.1):
Since the includes are usually discovered by Eclipse through the toolchain, check that you have an actual toolchain set (when I ran into this problem after importing a project, the toolchain was set to "No toolchain."):
Project -> Properties -> C/C++ Build -> Tool Chain Editor -> Current toolchain
If no toolchains appear in the dropdown, try unchecking "Display compatible toolchains only" and choosing a toolchain (I chose Cross GCC). When I saved the changes and re-opened the project properties to look at this field again, "Display compatible toolchains only" was automatically re-checked.
Then re-index the project:
Project -> C/C++ Index -> Rebuild
This solved the problem for me (the "pseudo-errors" disappeared, and the includes "folder" appeared under my project in the file system view).
Have you #included the correct files in your code? For std::cout it would be:
#include <iostream>
and for int64_t:
#include stdint.h