8

I have Eclipse Juno for C/C++ developers installed together with GNU ARM C/C++ Development Support plug-in from http://sourceforge.net/projects/gnuarmeclipse.

In my project I am using types like uint_32t, int16_t and uint8_t than normally comes from stdint.h. While I forced the Eclipse to see the standard headers of my compiler by directly pointing the directory where the include directory lies, mentioned types are not resolved. This gives me a lot of red markings about unresolved symbols and do some problems with code completion of the functions declared with these types.

The same problem is with standard macro definitions like GNUC - normally CDT see these for GNU C or GNU C++, but with toolchain set to ARM Windows GCC it don't. Strange.

What can I do to resolve that and return the main boost Eclipse gives in productivity?

Michał Fita
  • 1,183
  • 1
  • 7
  • 24

8 Answers8

8

I think I found solution to my problem. The problem was the CDT GCC Builtin Compiler Settings provider, which tried to run the gcc instead of arm-elf-gcc. I added prefix to the field Command to get compiler specs:¹ to invoke compiler by its proper name.

And voilà, all unresolved symbols disappeared.

Unfortunately I broke my project by changing toolchains (never do this if you have GNU ARM Eclipse plugin installed!) but that is another story.

¹ - It is under: Project Properties > C/C++ General > Preprocessor Include Paths, Macros etc., the tab Providers; Share settings entries between projects (global provider) has to be disabled to edit that field.

Michał Fita
  • 1,183
  • 1
  • 7
  • 24
1

please note that GNU ARM Eclipse plugins were updated in Oct 2013, and the new version has better support for path discovery, so this problem is less likely to occur.

changing toolchains was also fixed.

ilg
  • 138
  • 8
  • This should better be posted as comment, not a an answer. – Martin Prikryl Jan 22 '14 at 12:19
  • 1
    ok. my first attempt was to post a comment, but it was rejected (not enough rights, or something like this). – ilg Jan 22 '14 at 15:47
  • Hi Mr. @LiviuIonescu ,Please have a look at this question: http://stackoverflow.com/questions/38033130/how-to-use-the-gdb-gnu-debugger-for-microcontroller-debugging I know that you're probably one of the only people out there with deep knowledge about this topic. Thank you so much for helping. – K.Mulier Jun 25 '16 at 21:39
1

If you are using external Makefile, Eclipse has no way of knowing where your standard library for the target platform is located. The solution, that I have found, is to add the library include paths to

Project->Preferences->C++ General->Paths and symbols.

Vorac
  • 8,726
  • 11
  • 58
  • 101
1

I had the same issue and the solution from this page helped solving it:

  • Enter project properties -> C/C++->Preprocessor Include Paths,etc.->Providers
  • Click on CDT GCC Build Output Parser and change the compiler command pattern from (gcc)|([gc]++)|(clang) to (arm-none-eabi-gcc)|([gc]++)|(clang)
  • Click apply button
  • Click on CDT Built-in Compiler Settings Cross ARM and replace ${COMMAND} with arm-none-eabi-gcc.
  • Click apply button.
Vahid Shirvani
  • 46
  • 3
1

In Project > Properties > C/C++ General > Preprocessor Include Paths > Providers:

  • Enable CDT GCC Built-in Compiler Settings Cross ARM.

  • Set Command to get compiler specs to: 

    arm-none-eabi-g++ ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD "${INPUTS}".C
    • The important part is the .C on the end. This is usually set depending on the language. A small .c is used for C code, while the big C is used for C++. But there are no languages specified when using an external makefile or with the no toolchain option set.

  • Also, check Allocate console in the Console View to check the command is running properly and the variables are being correctly substituted.

  • Enable CDT GCC Build Output Parser and change the compiler command pattern from (gcc)|([gc]\+\+)|(clang) to (.*g++)|(.*gcc)|(.*[gc]\+\+) then apply changes. Use the Move up/down buttons to move it above the CDT GCC Built-in Compiler Settings Cross ARM.

You will also need to set Project > Properties > C/C++ General > Preprocessor Include Paths > Entries > CDT User Settings Entries to the following:

cdt user settings entries

In Preferences > String Substitutions you will need to create a var for gnu-arm-path pointing to your toolchain home.

Ideally, these should be found in CDT GCC Built-in Compiler Settings Cross ARM, but in my case they are not. I think it is to do with the fact that in a managed project, these entries are tied to each language. But with an external makefile the languages list box just says [Unspecified].

The Eclipse scanner provider system seems to be designed around CDT managed projects, making it a little trickier to get working when you are using an external makefile.

You can create a new managed project with an external makefile and view the scanner discovery console to see how it should be working. This is what I did.

vaughan
  • 6,982
  • 6
  • 47
  • 63
0

I came across a totally different solution to my version of this (in)famous problem. In my case search paths where not the problem because the compiler was working fine. Nevertheless, the editor complained about unresolved cstdint types everywhere: very annoying. Googling for the solution using the error message string was not fruitful and very frustrating.

I found the solution of this problem by chance in an answer ("There's now a new way to solve this without the GXX_EXPERIMENTAL hack") to the following thread:

Eclipse CDT C++11/C++0x support

Cheers

Community
  • 1
  • 1
Alkhwarizmi
  • 65
  • 7
0

In my case, the problem was that PATH did not direct to the compiler. So I added C:\Program Files (x86)\GNU Tools ARM Embedded\7 2017-q4-major\bin to the variable and it worked. To clarify: we had a convention, that we direct to the compiler with the variable GCCPATH.

Michał Fita
  • 1,183
  • 1
  • 7
  • 24
Jochen Gunzelmann
  • 61
  • 1
  • 5
-1

See if Project -> C/C++ Index -> Freshen All Files helps.

Mohamed Hemy
  • 1