The symbol __mulhi3
is indeed defined by libgcc.a
, like previously hinted by this link. The problem was that, when CMake's variable CMAKE_BUILD_TYPE was set to Release, the following flags are used (set through CMAKE_CXX_FLAGS_RELEASE):
-Os -DNDEBUG -mcall-prologues -ffunction-sections -fdata-sections -fno-exceptions
and it appears the use of optimization -Os
causes the internal GCC function __mulhi3
to be used. In that situation, somehow CMake wasn't looking for libgcc.a
in the place where it is in my system, which is /usr/lib/avr/gcc/4.8.0/libgcc.a
.
I already knew beforehand undefined reference
errors always happen when a library or object file defining a symbol is not linked in, and everybody helping me here were pointing in the right direction too, but I was really misled by the fact I was looking for libgcc.a
in the wrong place like this:
cd /usr/avr/lib
find -name "*.a" -exec avr-nm {} \; | grep "__mulhi3"
That was just returning loads of __mulhi3
marked as U
, which meant it should be defined somewhere else. Just after checking up my package contents for avr-gcc I found libgcc.a
was placed at /usr/lib/gcc/avr/4.8.0
.
Turns out in the end the whole problem was more related to CMake not being pointed the right place to look for libgcc.a
, which I got to work by adding the line:
set(CMAKE_EXE_LINKER_FLAGS "-L /usr/lib/gcc/avr/4.8.0")
to CMakeLists.txt
, which causes the following and successful linker invocation:
/usr/bin/avr-gcc -Wall -Os -DNDEBUG -w -mcall-prologues -ffunction-sections -fdata-sections -L /usr/lib/gcc/avr/4.8.0 -Wl,--gc-sections -lm -mmcu=atmega644p CMakeFiles/ucp-usc64.dir/main.c.obj CMakeFiles/ucp-usc64.dir/modutr_callbacks.c.obj -o ucp-usc64.elf -lc -lm avr-drivers/libavr_drivers.a libteleobjects/libteleobjects.a modutr-slave/lib/libmodutr_slave.a -lc -lm