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

[Joerg Wunsch]

"Peter Hierholzer" <address@hidden> wrote:

> To bypass the problem I did
>       copy the files of C:\WinAVR\avr\lib 
>               to the directory C:\WinAVR\avr\lib\avr2
>       copy the files from C:\WinAVR\avr\lib\avr4 to
>               the directory C:\WinAVR\avr\lib for atmega8
>       copy the files from C:\WinAVR\avr\lib\avr5 to
>               the directory C:\WinAVR\avr\lib for atmega16

That's strange.  There are no avr2 subdirectories ever referenced,
btw.  (Yes, this is ugly since it's non-orthogonal.)

> It looks like that the linker always goes to the directory
> C:\WinAVR\avr\lib regardless what I specify for the -mmcu.

I'd be surprised to hear that since it would imply that basically no
WinAVR installation could work at all except for avr2 MCUs.  I
personally cannot test what exactly is executed because I don't have
Windows and thus don't use WinAVR myself.  But you can do, just add a
-v option to the CFLAGS.

Are you sure you don't accidentally have an older installation of the
compiler or binutils around?

> I don't know how the compiler/linker handles the different avr2,
> avr3, avr4 and avr5 directories for linking. I appreciate if you can
> explain it or give a pointer where it is explained.

avr2 is not used at all.  In all other cases, the default library is
searched in the respective subdirectory, based on the -mmcu option
given on the command line.  Again, adding -v should reveal all the
details how the various pieces of the toolchain are called.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/