strange undefined symbols

[dabramson]

I used https://visualgdb.com/tutorials/arm/keil/tests/ to get started with a unit test project to test program logic, which is compiled as a lib, and consumed by the test project, and the application.

I have these two linker errors in the unit test project build that don’t make sense to me

Error: L6218E: Undefined symbol __rt_locale (referred from _printf_fp_dec.o).
Error: L6218E: Undefined symbol __rt_eh_globals_addr (referred from arm_exceptions_globs.o).

I looked through the linker output in the .lst file and it seems that the .o files are part of the binaries in the keil arm compiler. I’m not sure where the symbols are expected to be defined if not within the compiler libs. I’m guessing these are being linked in due to TinyEmbeddedUnitTest or the semihosting in the test projects. All other projects compile without issue, and the application runs fine on the hardware.

Am I missing a setting or a project define somehwere? Any assistance appreciated. I could supply the solution if necessary, but would only want sysprogs support to have access to it.

 

[support]

Hi,

This looks like something coming from the Keil compiler and not from VisualGDB. Please consider contacting Keil support regarding this.

[dabramson]

Hello,

I ask keil and they of course want more information. In an attempt to do that, I tried to go back and just do the tutorial exactly as it is presented in the hopes that I’d see the same undefined symbols at the link step. Unfortunately, the tutorial won’t compile after step 13. I undid everything back to step 10, and it built again.

I did step 11 only. It still builds, but with these warnings…

"C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/FastSemihosting.cpp", line 76: Warning: #550-D: variable "pSemihostingStruct" was set but never used
void *pSemihostingStruct = &s_FastSemihostingState;
^
C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/FastSemihosting.cpp: 1 warning, 0 errors
"C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/TestResourceManager.h", line 322: Warning: #1-D: last line of file ends without a newline
#endif
^
"C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/TestResourceManager.cpp", line 305: Warning: #1-D: last line of file ends without a newline
#endif

Then I did step 12. And it doesn’t compile…with these errors:

"main.h", line 41: Error: #5: cannot open source input file "stm32f4xx_hal.h": No such file or directory
#include "stm32f4xx_hal.h"
^

 

Then I do step 13 and get these errors:

"C:/Users/dabramson/AppData/Local/Arm/Packs/Keil/STM32F4xx_DFP/2.15.0/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f407xx.h", line 167: Error: #5: cannot open source input file "core_cm4.h": No such file or directory
#include "core_cm4.h" /* Cortex-M4 processor and core peripherals */
^
RTE/Device/system_stm32f4xx.c: 0 warnings, 1 error
Failed to compile system_stm32f4xx.c. armcc.exe exited with code 1

I’ve attached a zip of my project after step 13.

 

• This reply was modified 2 years, 10 months ago by dabramson.

Attachments:

You must be logged in to view attached files.

[support]

Sorry, we are not able to review specific projects for errors as a part of our regular technical support. Our best advice would be to follow the tutorial exactly as shown, make sure it works, and then use it as a comparison point against the broken project.

[dabramson]

I found that I was still using armcc with the tutorial project. The errors I got in my previous post where following the tutorial exactly as shown (except I used armcc instead of armclang).

I changed the tutorial project to armclang and now it builds. For sanity I switched it back to armcc to make sure it was still broken…but it wasn’t. So switching to armclang seems to have unstuck something. Very strange.

 

 

• This reply was modified 2 years, 10 months ago by dabramson.

[support]

You can always double-check the exact command lines used for the build by enabling verbose build (CMake) or inspecting the .rsp files (MSBuild). If different builds produce different results, there must be a difference in the compiler/linker command lines (or source file contents), and locating it should help understand what is going on.

Also, if you change global settings, such as the compiler type, please make sure you do a full rebuild to ensure there are no leftovers from the previous build.

[Author]

Posts