Why do we sometimes link with the math library

[erlingrj]

When I try compiling any of the Polulu robot examples with lfc 0.9.0 I get the following error:

[100%] Linking CXX executable Blink.elf
/usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: /usr/lib32/libm.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
gmake[2]: *** [CMakeFiles/Blink.dir/build.make:1436: Blink.elf] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1807: CMakeFiles/Blink.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2
lfc: error: CMake failed with error code 2
lfc: error: Compilation was unsuccessful.
lfc: fatal error: Aborting due to 2 previous errors.

This looks like the arm cross compiler tries to link with a 32-bit math library on my system. It is due to the following in the generated CMakeLists:

find_library(MATH_LIBRARY m)
if(MATH_LIBRARY)
  target_link_libraries(${LF_MAIN_TARGET} PUBLIC ${MATH_LIBRARY})
endif()

Why do we try to link with the math library in the first place? It does not seem to be required (if it is not found, no error or warning is produced). If it is needed, then we must add some extra checks in the generated CMakeListst.txt for the embedded targets so we don't try to link with any system libraries

[lhstrh]

I believe this is a vestige of a solution to the problem that whether math is included by default is different across platforms (specifically, Linux vs. macOS), so I think we decided to just include it always. This might not be a good choice for embedded systems, however.

[erlingrj]

Aha, that makes sense! Thank you, I suspect the error on my side is because I recently installed gcc-multilib which includes 32bit system libraries. I will look at a fix for the embedded targets.