Floating point library - linker problem

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
mogor
mogor's picture
Level: Hangaround
Joined: Mon. May 22, 2006
Posts: 135 View posts
#1
Posted by mogor: Wed. Nov 19, 2008 - 09:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I encountered a problem with floating point library (I guess).
When I use atan2() function, linker reports the following error:

c:/winavr-20080610/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr5\libc.a(atan2.o): In function `atan2':
(.text.fplib+0x70): relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in c:/winavr-20080610/bin/../lib/gcc/avr/4.3.0/avr5\libgcc.a(_addsub_sf.o)
c:/winavr-20080610/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr5\libc.a(inverse.o): In function `inverse':
(.text.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__divsf3' defined in .text section in c:/winavr-20080610/bin/../lib/gcc/avr/4.3.0/avr5\libgcc.a(_div_sf.o)
c:/winavr-20080610/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr5\libc.a(square.o): In function `square':
(.text.fplib+0x4): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in c:/winavr-20080610/bin/../lib/gcc/avr/4.3.0/avr5\libgcc.a(_mul_sf.o)

When I comment out atan2() function everything is ok. Can it be a problem of free memory?

I use AVRStudio 4.14 589 + WINAVR 20080610 + ATmega32

mogor
[/code]

Tags:

Tools, Compilers and General Programming, ATmega32
Top
mogor
mogor's picture
Level: Hangaround
Joined: Mon. May 22, 2006
Posts: 135 View posts
Posted by mogor: Wed. Nov 19, 2008 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found what was wrong.
I manually added math lib (-lm) to linker options. It seems the only way AVRStudio use libm.a is to use Libraries tab in Options.

Top
cmhicks
cmhicks's picture
Level: Hangaround
Joined: Thu. Nov 20, 2008
Posts: 335 View posts
Location: Cambridge, UK
Posted by cmhicks: Thu. Nov 20, 2008 - 10:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been struggling yesterday with the same problem, but from C++ source code, using AVR Studio.

My experience is that:

a) You must add the math library as mogor says with the [Libraries] tab, not with the [Linker Options] part of the [Custom Options] tab.

b) You must use .c as the extension for C files, and .C extension for C++ files, and let avr-gcc decide which compiler to use for each source file.

Note that you cannot use .cpp as the extension, because AVR Studio does not construct the makefile correctly in that case. To avoid this, I previously was using .c as the extension for all my source, and compiling it all with the C++ compiler by setting the [Custom Options] -> [External Tools] part of the project options to always use avr-g++. This does not work if you want to link the math library. I haven't dug into the makefile to see why this works one way and not the other, but am relieved that it does!

Thanks also to Tomasz and other contributors to the C++ micro howto, without which I would still be using C on the AVR.

Christopher Hicks
==

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Thu. Nov 20, 2008 - 06:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I haven't dug into the makefile to see why this works one way and not the other, but am relieved that it does!

Here's what I think of it (typing from memory, but we discussed this in a thread a week or two ago):

1) avr-gcc comes from the unix world where case matters. The extension .c is for C files and .C is (one of the) extension(s) for C++ files.

2) AVR Studio is a Windows program, and as such it is not case sensitive. It gladly accepts both files with .c and .C as he extension and calls avr-gcc to compile them. It has no notion of the .C extension being the convention for C++ files.

3) So Studio blindly hands over a .C file to avr-gcc thinking it is a C file, and avr-gcc takes it and treats it as a C++ file.

This is all by sheer luck. (The AVR Studio designers/programmers never thought of C++, or made an active descision to ignore it, in the sense not handling it at all).

When Studio gets to the linking stage this luck ends..

In order to get a long term reliable build process for C++, consider rolling your own makefile (but let Mfile help you if you feel like it).

EDIT: Typos corrected, and some text added.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top