Arm Mbed OS support forum

Compiling fails after update from 5.9.7 to 5.15.0: undefined reference to `main' in mbed_boot_gcc_arm

Hello everyone,

I needed to use some features which only exist in newer versions of mbed-os (namely the securitymanager of the ble feature) so I tried to update to the latest version. I am working in VSC, compiling with GNU Make 4.2.1.
Most of the compiling works (a lot of warnings but no error), it reaches 100%, prints out “Link mbed-os”, then gives me the following errors:

Compile [100.0%]: serial_api.c
[Warning] mxc_device.h@49,0: "TARGET_NAME" redefined
Link: mbed-os
BUILD/MAX32630FTHR/GCC_ARM/mbed-os/rtos/source/TARGET_CORTEX/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.o: In function `__wrap_main':
REDACTED/mbed-os\rtos\source\TARGET_CORTEX\TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c:89: undefined reference to `main'
collect2.exe: error: ld returned 1 exit status
[ERROR] BUILD/MAX32630FTHR/GCC_ARM/mbed-os/rtos/source/TARGET_CORTEX/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.o: In function `__wrap_main':

REDACTED/mbed-os\rtos\source\TARGET_CORTEX\TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c:89: undefined reference to `main’
collect2.exe: error: ld returned 1 exit status

I do have a main file in the folder which contains the mbed-os folder, it used to compile just fine with the previous version of mbed-os. I have tried to simplify the main, move it to various folders, but I don’t know how mbed_boot_gcc_arm identifies its __real_main variable.

Do you have any idea where this could come from and how to fix it?

Thanks in advance

Hello Clemence,

Passing a --wrap main option to the compiler+linker instructs the linker to use a wrapper function for the main symbol:

  • Any undefined reference to main will be resolved to __wrap_main.
  • Any undefined reference to __real_main will be resolved to main.

So when the main() function is called from the void mbed_start(void) function (defined in mbed-os\rtos\source\TARGET_CORTEX\mbed_boot.c) and the linker is not able to find a definition of a main() function it replaces it with __wrap_main(). The __wrap_main() function (defined in mbed-os\rtos\source\TARGET_CORTEX\TOOLCHAIN_GCC_ARM\mbed_boot_gcc_arm.c) calls __real_main():

...
extern int __real_main(void);
int __wrap_main(void)
{
	/* For backwards compatibility */
	return __real_main();
}
...

Since (according to the second rule above) any undefined reference to __real_main will be resolved to main, when the linker is not able to find any definition for the __real_main() function in your project source files (+ library files, if any) it repeats the search for a definition of the main() function. If it fails to find such it reports an error.
So based on the error report you provided it seems that there is no definition of the main() function in your project.

Check again:

  • The name of your main file. It should be main.cpp rather than main.c
  • Does the compiler output report contain message on successful compilation of the main.cpp file?
  • Does your main file define a main() function? (Maybe it happened to be commented out.)

Perform a --clean build (or manually delete the BUILD folder before compilation).

Hello Zoltan,

Thanks a lot for your answer, it is very clear.

While my compiler did not ouput a report on the compiling of the main.cpp file, I do believe this is where it failed: there is a new incldue error in my main.cpp file, which I can retrace all the way to a pthread include error. I’ll look into it today. So you were perfectly right, my main probably doesn’t compile.

Thanks!

Solved the include problem in the main, it still doesn’t compile. The main.cpp is considered as a source, it used to compile just right before version update.
I tried by completely emptying the main.cpp file and just having int main(){return 0;} in it, it gave me the same error.

Taking back the three points you asked me to check, all seems good, so I don’t exactly know in which direction to look now. Any ideas?

Have you tried to delete the BUILD folder and then recompile the project?

Yes, I have rebuilt from scratch for most of my attempts.

  • Does the linker report the same error (undefined reference to main)?
  • Does the compiler output report contain message on successful compilation of the main.cpp file?
  • I do not get to the point at which I get a Linked report, it usually is created after this point: what I used to get:
    Link: mbed-os
    Elf2Bin: mbed-os
    ±--------------------------------±-------±------±------+
    | Module | .text | .data | .bss |
    ±--------------------------------±-------±------±------+
    The linker report

What I now get:
Link: mbed-os
The error message

  • From what I can see, the main.cpp file is in the sources, it is part of the scan when building the project but it is not compiled. It used to be compiled before version change, but isn’t anymore.

Thanks a lot for your help!!!

Open the Make file and search for OBJECTS += main.o. If it’s missing then add such to the # Objects and Paths section as below:

...
# Project settings
###############################################################################
# Objects and Paths
OBJECTS += main.o
...

Hello!
I’m sorry, I’m coming back to this very late.
I went and looked a bit more into what is happening. My main.cpp file is currently in the MAX3263 folder, which also (but not only) contains my gitgnore, the mbed-os folder and the makefile.
If I create a folder in the MAX3263 folder, put the main here and add the folder to the sources of the project in the mainfile, the main is compiled and it all works.
However, having the file there creates a few errors in my main, but I should find my way around it.

So I’ll have one final question:

  • the compiler did scan for the main.cpp file when it was in MAX3263/, but did not compile it
  • the compiler also scan the main.cpp file when it is in, say, MAX3263/source/, and compiles it.
    Any idea why?

Thanks again for all your help, it was greatly appreciated.

In VS Code workspace or folder specific tasks are configured from the tasks.json file in the .vscode folder for a workspace. This file is also used to integrate external tools like compilers. I think the issue you reported might be related to that. Moreover, the configuration system has changed and it seems that Mbed is still using the legacy version (0.1.0). For more details have a look at: