Eclipse build failed for Blinky w/ SDK 14 - Make Error 2

[Mike W]

Hello!

I experienced the same errors as here and here when following the Eclipse gcc tutorial (7), but the solutions did not solve my problem.

I suspect this is related to my using SDK 14 instead of 13, as the project Makefile was tested with, but I did copy the attached Makefile.common to the directory, and it had no effect one way or the other. As for the general Makefile for the project, the following suggestions from other answers were individually then jointly applied without success after the build initially failed:

1. CFLAGS += -O0 -g3 # was already in the Makefile
2. changed components/toolchain/gcc/*.S to *.s (lower case) and changed "/Include" in Makefile line 54 to "/include"
3. rebuilt c++ index
4. commented Line 42 of Makefile (which referenced the non-existent nrf_delay.c)

Other important information:

1. Here attached is my Makefile.
2. I'm using Windows 10 pro.
3. The Console error indicates a missing file - the I manually checked all of the includes and there is one that does not exist - there is no bsp folder in examples. I don't know if this is related, but it's all I could find
4. Here attached is the verbose error from the Console.
5. Everything in the tutorials works fine with nrfjprog.
6. Make the folder utils are added to path and work readily in CMD - i.e. "where make" and "where mkdir" both point to the properly referenced GNU ARM Eclipse build tools folder.
7. I did see something about spaces in the tools path, but there are no paths with spaces referenced in the Makefile. Should I move the build tools and toolchain to a path without spaces and tell Eclipse to look for such?
8. The following lines show up with errors in Eclipse:

Makefile

• Line 127 under all: clean: $(NO_ECHO)$(MAKE) -f $(MAKEFILE_NAME) -C $(MAKEFILE_DIR) -e cleanobj

• Line 163 under $(OBJECT_DIRECTORY)/%.o: %.c: @echo Compiling file: $(notdir $<)

main.c

• Lines 51, 52, 54: Unresolved inclusions for <stdbool.h>, <stdint.h> and "boards.h"

• Line 65, while (true): symbol "true" could not be resolved

• Line 67, for (int i = 0; i < LEDS_NUMBER; i++): symbol LEDS_NUMBER could not be resolved

Thanks for your help!

[Mike W]

No effect from rebuilding index - neither project specific nor global C/C++. Also no effect from "re-resolve unresolved includes".

[Vidar Berg]

I noticed the multiple device and toolchain tabs after updating the plug-in, but it didn't seem to cause any errors. Also, they disappeared after I uninstalled previous version of the plugin and restarted Eclipse.

The thing actually builds if I replace LEDS_NUMBER with "4", but the problem is the unresolved includes at this point.

Did you make any changes to the code or makefile, and was there any errors reported in the console output? Note that Eclipse will report errors if it is unable to resolve dependencies, but the actual build should not fail if you are using the example Makefile.

By the way, I added a new screenshot to my answer which shows the include paths and symbols collected by the output parser. This list should include all include paths and defines (flags with -D prefix) used by the Makefile.

[Mike W]

I did not make any changes to the Makefile, and there are no errors in the console, just in the problems tab and in the form of red / yellow underlines in the code. The code does indeed run and produce a working hex output file, but you seem to be right about the preprocessor includes - Makefile finds the resources fine, but Eclipse does not.

My entries (as the SS shows, supplied by system and not editable) are not the same. None of the specific constant entries in your screenshot exist in mine. What's your recommendation?

[Vidar Berg]

Thanks for the clarification, just wanted to make sure that there weren't any build errors. Your SS shows that you already have the correct include paths and flags for the toolchain. So assume there aren't any warnings/errors for stdbool.h, stdint.h and 'true' in main.c anymore.

My last screenshot show the entries provided by the CDT GCC Build output Parser. It's this tool that collects the project specific paths and flags from the build log needed to resolve LEDS_NUMBER, nrf_delay.h, etc. Suggest that you inspect these entries and see if there are any, or if there are some that are missing. Note that the build output parser applies these entries individually for each source file so entries are not shown at project level. I.e., you need to select properties for one of the source files to view CDT GCC Build output Parser entries.

[Mike W]

Thanks for the patience and for the reply! There are none - they were all missing. I had to manually include and will synthesize all the working steps and post an answer.