avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] correct way to specify search path for avr's?


From: Steve Franks
Subject: Re: [avr-libc-dev] correct way to specify search path for avr's?
Date: Tue, 11 May 2010 12:52:37 -0700

On Mon, May 10, 2010 at 9:23 PM, Joerg Wunsch <address@hidden> wrote:
> As Steve Franks wrote:
>
>> Anyway, I've figured out my problem - set the library search path,
>> so I could find my libs, but now avr-gcc can't find the libs for the
>> m128.  How do I go about merging those two concepts?
>
> Normally, you don't have to hack those, they are supposed to be
> derived from the --prefix setting at configure/compile time.

Right, I've just found a way to sucessfully override it in my makefile
somewhere.

>> -Wl,-Map=.map,-u,vfprintf,-lprintf_flt,-u,asin,-lm,-lgcc,-L/usr/local/avr/lib
>
> That's a lot of stuff in a single option.  Why's that?  Why are you
> forcing "asin" as an undefined symbol?  Why are you trying to place
> libm.a and libgcc.a manually there?
>
> Normally, you should be able to get away with just
>
> -Wl,-uvfprintf,-lprintf_flt -L./../lib/ -lm

Historical.  This makefile came from mfile around the time the m128
was only a few years old.

>> /work/a/ports/devel/avr-libc/work/avr-libc-1.6.8/avr/lib/avr2/../../../libc/stdio/vfprintf.c:338:
>> undefined reference to `__mulhi3'
>
> That's because you managed it to link an avr2-architecture file.  avr5
> doesn't have __mulhi3 in its library because the compiler can use the
> hardware multiplier instead.

At least we're in agreement.  I'll mess with the LDFLAGS...I did force
it with a -L/.../avr5/ and it links again, just have to figure out how
to let it default to that.

Thanks,
Steve



reply via email to

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