undefined reference to `memcpy' - EmbDev.net

undefined reference to `memcpy' - EmbDev.net:

Re: undefined reference to `memcpy'

Author: Magnus Sundell (Guest)

Posted on: 2010-12-12 18:26

---

For what it's worth, I had the same issue the other day. I was working 
on an ARM project with the STM32 Cortex-M3 MCU. The quick fix I tried 
was to use gcc.exe instead of ld.exe for linking.

It removed the problem with undefined references, but after debugging 
the project I discovered that the toolchain inserted illegal 
instructions for the Cortex-M3. To be specific, every time e.g. memcpy 
or memset would be called, the assembler instruction generated was BLX 
address, which generates a HardFault on Cortex M3 (or so I think). On 
this type of processor, it should only generate BLX register.

So I switched back to ld.exe for linking, but now had to specify the 
-lgcc and -lc switches manually. I also had to specify where ld should 
look for libraries. After trying a few times, I discovered that the 
YAGARTO toolchain includes libc.a and libgcc.a libraries specifically 
for Thumb and ARMV7-M cores. Including these in LFLAGS did help ld.exe 
find the libraries, but the undefined references remained.

So I had a read on the -l option for GCC linker. The example with 'foo.o 
-lz bar.o' inspired me to move the -L and -l options to the end of the 
link command. I.e.

$(LD) $(FLAGS) -o main.out <objfiles> 
-L"E:/yagarto/lib/gcc/arm-none-eabi/4.5.1/thumb/v7m" -lgcc 
-L"E:/yagarto/arm-none-eabi/lib/thumb/v7m" -lc

This removed the problem with undefined references, and now the build 
generates correct BLX instructions (for my project).

So it seems to be that the -L and -l options should be placed after the 
list of object files which are linked. As the GCC documentation states, 
if an object file listed after the libraries uses functions from those 
libraries, they may not be loaded (order matters).

I am aware that this thread is over two years old, but I thought that 
I'd provide my two cents in solving a problem which I have myself spent 
some hours battling. At the same time, present a solution to a 
STM32-specific problem with invalid BLX instruction being generated.

// MS

'via Blog this'