[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_A
[avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL"
Mon, 7 Nov 2005 07:04:00 +0100
Mozilla/5.0 Galeon/1.2.13 (X11; FreeBSD i386; U;) Gecko/0
Follow-up Comment #6, bug #14855 (project avr-libc):
> > This rather looks like a libgcc bug to me then. libgcc should not
> > supply anything that is supplied by avr-libc.
> Now there is an opportunity to choose, what base float arithmetic
> functions to use: high-quality from 'libgcc' or compact and fast
> from 'libm'.
Well, no, that can't be the way. libgcc is always linked, and any
calls into it need to be far calls (where applicable). If we want to
supply two different libm.a options, then we should offer that as a
user-selectable option, but still keep it outside of libgcc.a.
I tend to classify these routines as `broken' if they don't yield the
same results as libgcc.a ones. If we supply replacements for libgcc
functions (because we could get the job quicker done than the generic
code), they need to behave exactly the same. Even then, I think these
functions should rather be imported into libgcc.a then instead.
So I think that bug should be resolved by using XJMP instead of
Reply to this item at:
Message sent via/by Savannah