Re: AW: AW: [avr-gcc-list] Linking Problems with undefined reference to '__mulhi3' when using fdevopen on atmega8

[Joerg Wunsch]

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
from.

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/