[Top][All Lists]

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

Re: [avr-gcc-list] simulavr build snaggle

From: Theodore A. Roth
Subject: Re: [avr-gcc-list] simulavr build snaggle
Date: Wed, 13 Aug 2003 09:52:56 -0700 (PDT)

On Wed, 13 Aug 2003, Terry Porter wrote:

> >    Soooo, I'm kinda hoping a kind soul has a good suggestion.
> I have a workaround :-
> .........
> Copy the libs that avr-libc-20030512cvs installed to where Avr-Gcc
> really wants them
> This was where I hit my first snag, because after compiling my test
> program, when it came to linking, the linker barfed because it
> couldn't find a crts*.o file. It seems that the libraries installed
> by avr-libc-20030512cvs are in the wrong place, or gcc-avr is
> looking for them in the wrong place, so :
> cp -r /usr/local/avr/lib/*    /usr/local/avr/lib/gcc-lib/avr/3.3
> ...................

This should not be necessary. I suspect that either avr-libc or gcc
were configured incorrectly, possibly both. Gcc should only be looking
for libs that gcc provides in $(prefix)/avr/lib/gcc-lib.

On my system, I configure both with --prefix=$HOME/local/avr and
$HOME/local/avr is a sim-link to $HOME/local/avr-<date> so I can
revert to a working tool chain should I hose things (or the cvs
versions I work from are hosed). I have a script which automates
updating my local cvs trees, configuring, building and installing all
the tools and handles the dated directory.

Here's where crts8535.o got installed (the first one is in the cvs
src dir):

address@hidden:~$ locate crts8535.o

Notice that the path doesn't mention gcc it. In theory, you should be
able to have multiple versions of avr-gcc installed and all of them
using the same avr-libc headers and libs.

Ted Roth

reply via email to

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