Eclipse 3.7 cannot resolve Types in C++ Editor

Question

I recently changed from Eclipse 3.6 to Eclipse 3.7 , which I am using for C++ development in Ubuntu 11.04 .

With Version 3.6 I had no big troubles, except that I always had some issues with the indexer. Now with Version 3.7 it begins marking unresolved Types as Errors. Since the indexer seems to dislike me even more, my Eclipse apparently doesn't know types like uint16_t or size_t.

In contrary to the displayed errors in the code editor, my compiler has no problems with compiling the code and resolving all symbols and types, so this seems to be a problem of the IDE itself.

Are there any ways to avoid this behavior, because all the red underlines make my code more and more unreadable...?

Update:

Okay with some research and the answer from Dennis I found out that I need to add some paths to Project Properties/ C/C++ General/ Paths and Symbols

Since I am building for a PowerPC instead of a I32 target, I can not just add /usr/include . Instead I needed to add

/usr/powerpc-linux-gnu/libc/usr/include

for all the standard headers (like stdint.h). Also I needed:

/usr/lib/gcc/powerpc-linux-gnu/4.5.1/include

for the stdarg.h.

Now almost all the errors are gone. The only function which still troubles me is printf from the header stdio.h. I looked it up and the header file itself lies within the included paths. Still I get an Error which says Function printf could not be resolved. I want to note again, that these are just errors displayed by Eclipse - The compiling itself works fine.

So this actually throws up 3 questions:

1. In the project properties the Paths and Symbols section coheres with the include Paths out of the C++ Build/Settings/C++ Includes section. This means adding/deleting a path in one of those sections directly affects the entry of the others. Since the C++ Includes directly coheres with the Compiler I wonder why the compiler can compile correcty ( and finds the headers ) even if they arent passed to him as a path? Is there some kind of standard path GCC uses, which I don't know about?

2. Why doesn't he find printf in eclipse? The headerfile stdio.h is included and it also contains the declaration of printf - so why does the Eclipse Code Editor tell me that it can't resolve it?

3. Why are the header files divided so much? I am aware that I need other header files if I am building for another traget (e.g. PowerPC) - But why does the GNU GCC separate those headers in different dirs?

Albrecht

Answer 1

The red underlines for common types are usually caused by not having your standard library in your include path. Look at your includes for your project... they are in the project properties. Ensure that your C++ includes have an entry that matches the C++ standard libs folders for the compiler you are using.

Valet

I am using the powerpc-linux-gnu-g++ compiler. In my C++ Build Settings I also configured the according include path (/usr/powerpc-linux-gnu/include/c++/4.5.1). This path I also added to the Project Include paths...unfortunately nothing changes.. – Albrecht

size_t is defined in <cstddef> among others. If you #include it in your file see if it makes the red lines go away. If not, see if the #include <cstddef> is underlined with a yellow line. If so hover over it, and if it says that it cannot find it then you have a problem with your include setup. Also try re-building the index for your project. – Valet

Hi Dennis ,thank you for your Input - I just updated the question a bit. Maybe you can help me further. – Albrecht

Your question sounds very specific to your target platform which I am not familiar with... sorry. Glad you found the advice helpful though – Valet

Answer 2

After hitting this problem and a search revealing two stack overflow questions hitting the same problem, I figured I would submit how I fixed it after it annoyed me enough to actually investigate.

I'm running Fedora and annoyingly, it has a stddef.h file in /usr/include/linux.... which is actually empty. So even though I had the compiler's stddef.h in the include path, the indexer was actually parsing this other empty file. So what needed done was:

Prefix your paths and symbols list with the compiler specific include path (in my case it was /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/) to avoid the other empty stddef.h from being parsed.

Billington

Prefix is important. I had /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/ included but it's at the bottom and cannot be moved up. I had to add another entry and move it to top to make it work. Apparently other directories in the list have a wrong version which messed things up. – Darmstadt

Answer 3

I'm using Eclipse (Mars.1 Release 4.5.1, Build id: 20150924-1200) with an ARM compiler (arm-none-eabi, 4.4.1). I had exactly the same problem as you. My former path was:

D:\test\CodeSourcery\Sourcery G++ Lite\lib\gcc\arm-none-eabi\4.4.1\include

Then i discovered another include directory (postfix: 'fixed') at the compiler directories:

D:\test\CodeSourcery\Sourcery G++ Lite\lib\gcc\arm-none-eabi\4.4.1\include-fixed

This fixed all my errors concerining type-misdetection (e. g. uint16_t).

Nievesniflheim