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).
This question is related to
c++
eclipse
include
eclipse-cdt
include-path
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 this happen after updating gcc and eclipse on ArchLinux. What solved it for me was Project -> C/C++ Index -> Rebuild
.
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.
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...
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!
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.
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:
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)
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 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
Use global provider shared between projects
(you can also modify the global provider if it fits your need)Command to get compiler specs
, add -std=c++11
at the endIndex
->Rebuild
Voila, easy and simple. Hopefully this helps.
Note: I am on Kepler. I am not sure if this works on earlier Eclipse.
For me it helped to enable the automated discovery in Properties -> C/C++-Build -> Discovery Options to resolve this problem.
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:
Properties
C/C++ General
> Paths and Symbols
> Includes
tabAdd...
File system...
lib\gcc\x86_64-pc-cygwin\4.8.2\install-tool\include
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.
mine was bit easy to fig out right click >run as>run configration
check boxes include system lib,inherited mains
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:
The only problem with this is that gcc will complain that the symbol is already defined(!) but the compile will complete as before.
Source: Stackoverflow.com