Linker errors with arm-rtems-gcc

I am working on developing some unit tests for someone else’s firmware developed using RTEMS 5.3 which is built with arm-rtems-gcc version 7.5.0 and Newlib 7947581 for a Xilinx Zynq device.

The unit test framework tries to create it’s own .elf file out of the test harness code and the firmware function being tested without the remaining firmware code, RTEMS kernel, etc. In essence, it is trying to compile a small bare metal example using the RTEMS gcc compiler.

When it gets to the linking section, I am getting a lot of errors.

One group of errors are undefined references for functions such as __getreent, _Mutex_recursive_Acquire, _Mutex_recursive_Release plus others all of which are referenced to calls from source code in gcc-7.5.0/newlib/stdio. That suggests that the linker is missing a reference to a library but I can’t tell which one.

The other errors relate to the source files in the unit test which report:

error: build/src/main.o uses VFP register arguments, build/test_harness.elf does not
failed to merge target specific data of file build/src/main.o

The compiler and linker are passed -mcpu=cortex-a9 -mfpu-vfpv3 -mfloat-abi=hard

Any ideas on what needs fixing?

-Andy.

is provided by librtemscpu.a (at least in RTEMS 6) that is, you need to add -lrtemscpu to the command line. You can find the static libraries with find <top-directory> -name \*.a and see what they provide with nm --defined-only <libXYZ.a>. May be you need to add the directory -L<dir> containing the library to the linker command.

The other error error: build/src/main.o uses VFP register arguments, build/test_harness.elf does not – and that may be the real source of your trouble – indicates that your main.o is compiled with different (hardware related) compiler flags than test_harness.elf. This means these files are incompatible and cannot be linked together. I do not know what you compile when and how. But the arguments describing the hardware must fit together in all compile steps – the libraries produced by RTEMS build, the .o-files you produce your self, etc. The best is probably to check which options are used by waf or make when you compile RTEMS.