Converting a project from MCUxpresso IDE to run on GNU GCC through make

[eablan]

I have taken a project that was setup with MCUxpresso IDE, and using the auto-generated make files to simply run 'make all' command through command line. The project builds perfectly fine with MCUxpresso IDE and choosing the Newlib (nohost) with the managed linker script option checked.

When I run 'make all' through command line I see errors saying the following:

/usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: cannot find libcr_newlib_nohost.a: No such file or directory
collect2: error: ld returned 1 exit status

This makes sense as my arm-none-eabi-gcc binary running GNU GCC ARM 10.3.1, does NOT have a file named libcr_newlib_nohost.a. That file simply does NOT exist in all of GNU GCC ARM. Which is a little interesting, and a little scary because I thought MCUxpresso was using GCC ARM as is, just downloading it as a part of the SDK as a convenience for users. Clearly that's not the case. 

However, when I manually edit the <Project>_Debug_library.ld auto generated linker script to the following:

GROUP (
  "libgcc.a"
  "libc.a"
  "libm.a"
  /*"libcr_newlib_nohost.a"*/
  "libnosys.a"
)

Running 'make all' using the auto-generated make scripts with the linker script modification above works, and the project builds with no errors.

My question is the following:
1. Is the libnosys.a (GNU GCC ARM), the equivalent to the libcr_newlib_nohost.a (NXP)?  Seems that it contains the needed stub functions if it linked properly.

2. The code was linked correctly and runs as intended. No crashes, no issues. So is my compiled /linked code safe?

[ErichStyger · Accepted solution]

The IDE uses its own internal GNU ARM GCC toolchain and somewhat custom libraries to support all the different semihosting options. So if you create the linker file from the IDE, it will use these custom libraries. If you use a different tool chain, these are not found.

You could change the linker script (as you did) or simply using the compiler/build tool chain in the library.

And as a heads up: you should use the same gdb from the tool chain you have used to build the binaries, just to avoid any possible issues.

PS: you might have a look at https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-...