[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: AW: [avr-gcc-list] Linking Problems with undefined reference to

From: Joerg Wunsch
Subject: Re: AW: AW: [avr-gcc-list] Linking Problems with undefined reference to '__mulhi3' when using fdevopen on atmega8
Date: Mon, 6 Oct 2003 23:46:16 +0200 (MET DST)

As "Peter Hierholzer" <address@hidden> wrote:

>Linking: test.elf
>avr-gcc -v -mmcu=atmega8 -DF_MCU=16000000 -I. -g -Os -funsigned-char
>-funsigned-bitfields -fpack-struct -fshort-enums -W
>all -Wstrict-prototypes -Wa,-adhlns=test.o -I. -Ic:/avr/source/include
>-std=gnu99 test.o  --output test.elf -Wl,-Map=tes
>t.map,--cref -Lc:/winavr/avr/lib -Lc:/avr/source/uart/

This is the mistake.  You explicitly request -Lc:/winavr/avr/lib as a
library search path on the compiler command-line.  This makes the
linker not lookup the libc.a from the c:/winavr/avr/lib/avr4
subdirectory as it is supposed to be, and as it would happen if you
omitted the above option.  Just check your Makefile where this comes

libgcc.a doesn't suffer from this problem since the compiler driver
always used the full pathname to it when calling the linker.

Sure, if the directory structure were more orthogonal, with an
avr2...avr5 subdirectory for each `architecture' (and no libc.a in the
toplevel lib directory), this would not happen...  But that's a
question to Marek since it needs to be fixed in the entire
gcc/binutils combination.
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]