21

I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1

Then the following problem occurs:

Eclipse errors

I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....

Although lots of errors occur, compiling was finished successfully!

I have tried to use g++ to compile the code, it had no problem.

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
zonyitoo
  • 213
  • 1
  • 2
  • 5
  • I found some [links](http://www.eclipse.org/forums/index.php/t/216821/) talking about this issue, but wasn't able to find a definitive solution. Any ideas? Coding with all these messages becomes really annoying!! – Matteo May 21 '12 at 13:19
  • 1
    @zonyitoo, I think my answer is correct. Could you please review, and mark if you agree? – Catskul Mar 16 '14 at 10:02
  • @zonyitoo - You should accept one of the answers if it helped you. – Matteo May 16 '17 at 20:50

8 Answers8

8

The problem is that there are a bunch of include directories that are missing from the indexer's perspective.

Adding the following worked for me, but may depend on your particular setup where they actually exist:

/usr/include/c++/4.6.1
/usr/include/                
/usr/include/c++             
/usr/include/c++/4.6         
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/

They can be set in Project>Properties>C++ Include Paths

Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.

Catskul
  • 17,916
  • 15
  • 84
  • 113
  • If the problem was with missing include directories, the line “#include ” were underlined with red as well saying: “unresolved inclusion”. At the screenshot we can see that it is not the case. – Artem Pelenitsyn Jan 24 '12 at 08:22
  • It's not a problem finding the top layer includes, but rather the bottom layer "bits" includes deep within. If you eclipse finds "iostream" but not something that "iostream" itself includes, it will not underline it. – Catskul Jan 25 '12 at 01:17
  • Ok, that's right. After I added all this to my project path it reduces number of errors hugely. But there're some of them stay. Errors like “No such constructor for type X”, where X is std::vector, std::map etc.… There are problems with C++11 feautures (like “Function 'bind' could not be resolved”). – Artem Pelenitsyn Jan 25 '12 at 20:11
  • Probably a similar issue. I may have missed a few paths as I guessed at what was needed. You can keep following the headers until you see an include at the top of one that is underlined as missing, and then search /usr/include to find it. – Catskul Jan 26 '12 at 17:41
  • @Catskul - can u tell me what you think about the solution I proposed?does it help you resolve your issues (if you still have them)? – Matteo May 28 '12 at 06:56
5

Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.

Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.

A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).

The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.

Eclipse help docs tell us what this command does:

if set to "true", any cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches.

There are three ways one can use the -clean command line argument:

  1. Edit the eclipse.ini file located in your and add it as the first argument on the first line.
  2. Edit the shortcut you use to start Eclipse and add it as the first argument.
  3. Create a batch or shell script that calls the Eclipse executable with the -clean argument.

The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.

This page solved the problem to me!Hope it can help everybody else.

Matteo
  • 7,924
  • 24
  • 84
  • 129
2

In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.

Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.

Chuong
  • 21
  • 1
  • Many thanks for the hint. This solved my problem where I already had added the right include paths, but for whatever reason the indexer still has not found the right header files. – naich Oct 17 '12 at 10:03
1

Updated index option to active build configuration works for me,

also I removed some files from the file list of being indexed up-front,

user1546658
  • 11
  • 1
1

The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:

Window > Preferences > C++ General > Code Analysis

Go there and un-check all the boxes to disable it.

Gyan aka Gary Buyn
  • 12,242
  • 2
  • 23
  • 26
  • 5
    This is not a good answer. The question is asked to solve the problem not hiding it. Code analysis is an important tool for development. It is really not a good idea to disable it. – Vincent Feb 23 '12 at 15:02
1

When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case). After this 'Path and Symbols' will show the correct path to the include files of your compiler. The bugs will disappear. This setting was useful only during creating the project, setting it later did not help.

In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.

Community
  • 1
  • 1
Erzsébet Geréb
  • 11
  • 1
0

Ok here is what worked for me:

  • deleted the path to the header files I created from the include path

  • compiled the project (obviously the compiler complains since it is missing user-defined headers)

  • reinserted the path to the header files I created

  • compiled the project again - worked perfectly

I can't explain the case :(

iueae
  • 1
0

I am answering here because this is the closest question to my problem.

I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.

However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:

function 'fprintf' could not be resolved
function 'memset' could not be resolved

even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.

If I went back to Helios, the problems went away.

I tried reindexing, to no avail. I checked my include paths, and they were:

c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include

At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".

I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.

Now I knew that it wasn't just a Qt problem.

I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!

It was then that I took another look at the include paths. They had been updated by the compile step to the following:

c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++

These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.

So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.

The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.

Dan
  • 1,823
  • 16
  • 18