[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: [avr-gcc-list] Linking Problems with undefined reference to '__
Re: AW: [avr-gcc-list] Linking Problems with undefined reference to '__mulhi3' when using fdevopen on atmega8
Mon, 6 Oct 2003 17:13:12 +0200 (MET DST)
"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