Linker Error relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3'

[Gerald F. (geraldf)]

Hallo, ich nutze Eclipse mit avr auf einem MAC, und bekomme vom Linker 
bei einem meiner Projekte folgenden Fehler:

avr-g++ -Wl,-Map,TriCopter.map,--cref -L"/Users/petrasteinhoff-fuchs/Documents/workspace/Core/Release" -L"/Users/petrasteinhoff-fuchs/Documents/workspace/TriLib/Release" -mmcu=atmega328p -o"TriCopter.elf"  ./DCM.o ./Global.o ./Sensors.o ./Servo.o ./TRI_Radio.o ./Tricopter.o ./UserConfig.o   -lCore -lTriLib *-lc -lm*
/usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/libm.a(square.o):../../../libm/fplib/square.S:43: relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in /usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/avr5/libgcc.a(_mul_sf.o)

Ich bin soweit durchgestiegen, dass es an irgendwie an den 
mathematischen Funktionen. Ich habe auch gelesen, dass es mit den 
"switches" -lm-lc gehen sollte, aber bei mir macht es das leider nicht. 
Hat jemand eine Idee?


Danke
Gerald

[(prx) A. K. (prx)]

Gerald Fuchs schrieb:

> mathematischen Funktionen. Ich habe auch gelesen, dass es mit den
> "switches" -lm-lc gehen sollte

Zusammengeschrieben sicher nicht. Sondern als -lm -lc. So dass der 
Compiler in der oben gezeigten Aufrufzeile -lc -lm -lc sieht.

Bei avr-gcc gibts die Fliesskomma-Runtime zweimal, eine in der avr-libc 
und eine in der libgcc. Erwischt der Linker die Funktionen in der libgcc 
hast du ein Problem.

[Johann L. (gjlayde)]

http://gcc.gnu.org/PR28718

lässt sich leider nicht innerhalb des avr-Teils von GCC lösen.

Was macht eigentlich jump-relaxing, genau für sowas ist das doch da 
(kenn ich zumindest so von anderen Maschinen)

[Jörg W. (dl8dtl) (Moderator)]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718

Kurz und gut: du wirst nicht umhin kommen, das mit -nostdlib zu
linken und dann die gewünschten Bibliotheken manuell reinzuziehen.

Ich betrachte das nach wie vor als einen Bug im GCC, aber siehe PR:
die GCC-Leute sehen da keinen Handlungsbedarf.  Der Bug ist dabei
in meinen Augen nicht das direkte Problem der libm.a und deren
Inkonsistenz mit der libgcc, sondern die Tatsache, dass im C++-Modus
(und nur in diesem) versucht wird, gegen die libstdc++ zu linken,
bevor irgendwelche vom Nutzer benannten Bibliotheken gefragt werden.

Da das AVR-Setup keine libstdc++ hat, ersetzt GCC dann (weil sie den
Platz offenbar nicht freilassen wollen in der Folge) stattdessen die
libgcc an deren Stelle, was einem hier in diesem Falle nun (aufgrund
der Inkonsistenz zwischen libgcc und libm) zu 100 % auf die Füße
fällt.  Andrew Pinski mag ja Recht haben, dass wir in einem Setup,
bei dem wir keine Patches in die libgcc bekommen, die eigentlich dort
hingehören würden (sodass wir sie in der libm führen) in der Tat ein
Problem haben, aber erstens kommt ihm dabei offenbar nicht in den Sinn,
dass es gerade die Lizenzpolitik der FSF ist, die genau dazu führt,
dass nicht alles aus der libm.a auch akzeptabel für die libgcc.a ist,
und zweitens ignoriert sein Kommentar eben auch, dass es in meinen
Augen widersinnig ist, eine Systembibliothek (egal, ob nun libstdc++
oder libgcc) vor den Nutzerbibliotheken überhaupt zu durchsuchen.

Wenn dich das alles genauso stört wie mich, dann hinterlass' deinen
Senf da im Bugtracker.

Edit: Johann war schneller.

[Johann L. (gjlayde)]

Mögliche Lösungen wurden diskutiert in

Beitrag "Re: avr-gcc und avr-libc: wie passt das zusammen?"

aber wirklich was brauchbares war da nicht dabei.

[Jörg W. (dl8dtl) (Moderator)]

Naja, die "nach vorn"-Lösung wäre es, einfach endlich mal die
libstdc++ zum Laufen zu bekommen ... kann eigentlich nicht so viel
sein, wenn sich denn endlich mal jemand, der auch an C++ interessiert
ist, dazu aufraffen würde.  Ich wette, dass man sogar exceptions
hinbekommen würde (auch wenn sie so teuer sind, dass man sie nicht
unter vielleicht 32 KiB flash-ROM haben will).

[Gerald F. (geraldf)]

A. K. schrieb:
> Gerald Fuchs schrieb:
>
>> mathematischen Funktionen. Ich habe auch gelesen, dass es mit den
>> "switches" -lm-lc gehen sollte
>
> Zusammengeschrieben sicher nicht. Sondern als -lm -lc. So dass der
> Compiler in der oben gezeigten Aufrufzeile -lc -lm -lc sieht.
>
> Bei avr-gcc gibts die Fliesskomma-Runtime zweimal, eine in der avr-libc
> und eine in der libgcc. Erwischt der Linker die Funktionen in der libgcc
> hast du ein Problem.

Es scheint, dass er die libgcc erwischt hat. In der Fehlermeldung steht 
ja:`__mulsf3' defined in .text section in 
/usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/avr5/libgcc.a(_mul_s 
f.o).

Ich habe auf meiner Platte mal gesucht, aber finde nur eine libgcc.a , 
aber keine avr-libc.a.
Gerald

[Jörg W. (dl8dtl) (Moderator)]

Die heißt auch nur libc.a, dass sie für den AVR ist, wird nur
am Namen der Verzeichnisse deutlich, in denen du diese (es gibt
deren mehrere) findest.

Dass dein Problem genau darin besteht, war schon weiter oben völlig
klar.  Dass es keine befriedigende Lösung dafür gibt, leider auch.
Linke den Job mit -nostdlib, und benutze dann (in dieser Reihenfolge)
-lm -lc -lgcc -lc als explizit benannte Bibliotheken.

[Gerald F. (geraldf)]

Hallo Jörg,

das scheint das Problem zu beheben, allerdings kann er _heap_end nicht 
auflösen.

Hast Du auch noch einen Tip dafür?
Vielen Dank.


undefined reference to `__heap_end'

[Jörg W. (dl8dtl) (Moderator)]

__heap_end sollte aus dem crt0.o-File kommen.  Das müsste eigentlich
noch gelinkt werden, sofern du nicht gerade -nostartfiles mit angibst.
Für den ATmega328P ist der genaue Name "crtm328p.o", ggf. müsstest
du diese Datei als erste Objektdatei beim Linken explizit angeben.

Wenn du dem Compiler die Option -v mit auf den Weg gibst, dann
erzählt er dir ein wenig, was er denn alles so anstellt mit den
backend tools.

[Gerald F. (geraldf)]

Hallo Jörg,
super, das wars. Jetzt konnte ich es ohne Fehler linken.

Vielen, vielen Dank für die klasse Hilfe.

Gerald