Forum: Compiler & IDEs neuer Compiler mag libm.a und libc.a nicht


von Reinhard M. (reinhardm)


Lesenswert?

Hallo,

ich habe meine Klassenbibliothek allgemeingültiger gemacht und wollte 
jetzt zusätzlich weitere Prozessoren unterstützen.
Die megas von 88 bis 640 übersetzen soweit ohne Fehler, aber ab mega1280 
gibt es die Fehlermeldungen:
1
/usr/local/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: skipping incompatible /usr/lib/avr/lib/libm.a when searching for -lm
2
/usr/local/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: skipping incompatible /usr/lib/avr/lib/libc.a when searching for -lc

Hm, ich habe binutils, den compiler selbst und avr-libc jeweils neu 
gebaut.

Was habe ich übersehen?

: Verschoben durch Admin
von hp-freund (Gast)


Lesenswert?

http://www.avrfreaks.net/forum/skipping-incompatible-libca-when-searching-lc

Die letzten 3 Antworten könnten evtl. hilfreich sein.

von Reinhard M. (reinhardm)


Lesenswert?

Danke für die schnelle Antwort!
Auch für den Hinweis auf die letzten 3 Beiträge.

Trotzdem verstehe ich es nicht.
Bei jedem Prozessorwechsel mache ich ein "make clean" und erst danach 
ein "make".
Ich habe das Makefile extra so erweitert, dass auch alle Zwischendateien 
bei einem "make clean" entfernt werden.

Wie kommt der compiler jetzt dazu, die falschen Libs zu nehmen?
Die Trilogie für den neuen compiler wurde jeweils ohne prefix übersetzt, 
wäre also in /usr/local/... zu suchen und nicht in /usr/lib/avr/...

Bei den Hilfen zum compilerbau hieß es, dass ich immer auch die avr-libc 
bauen müsse. Seither habe ich mir das angewöhnt, bin also sicher, dass 
ich die avr-libc nach dem Bau (und der Installation) des compilers 
übersetzt habe.

Deshalb bin ich jetzt ziemlich verunsichert.
Wo kann der falsche Hinweis denn herkommen?

von Reinhard M. (reinhardm)


Lesenswert?

Ok, den ersten Pebcak habe ich gefunden.
Ich hatte Pfade für include und lib im Makefile angegeben =:O

Kaum korrigiert, moniert der compiler jetzt die richtigen libs:
1
/usr/local/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: skipping incompatible /usr/local/avr/lib/libm.a when searching for -lm
2
/usr/local/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: skipping incompatible /usr/local/avr/lib/libm.a when searching for -lm
3
/usr/local/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: skipping incompatible /usr/local/avr/lib/libc.a when searching for -lc

Ein Kommentar bei den Freaks war ja, dass die Bibliotheken korrupt 
wären.
Habe beide mit avr-nm gelesen - die Ausgabe erscheint auf den ersten 
Blick plausibel.

Jetzt weiß ich nimmer weiter :(

... bzw:
in den Unterverzeichnissen avrxx gibt es jeweils auch eine libm.a
Müsste ich etwas für jeden Prozessor ein anderes Lib-Verzeichnis 
angeben?
Wenn ja, wie komme ich von dem Prozessor zum verwendeten Kürzel?
Also ich verwende _AVR_ATmega2560_ und habe avr3, avr31, avr35, avr4, 
avr5 und so weiter ...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Reinhard M. schrieb im Beitrag #4772072:

Also ich verwende _AVR_ATmega2560_ und habe avr3, avr31, avr35, avr4, avr5 und so weiter ...

Auch avr6? Das wäre die zuständige Architektur für einen ATmega2560.

__AVR_ATmega2560__ definierst du hoffentlich nirgends selbst, oder?

Hast du ein korrektes -mmcu= überall, also auch beim Linken?


von Reinhard M. (reinhardm)


Angehängte Dateien:

Lesenswert?

Hallo Jörg,

danke für Deine Unterstützung!

Jörg Wunsch schrieb:
> Auch avr6? Das wäre die zuständige Architektur für einen ATmega2560.

Klar! Auch die ;)

> _AVR_ATmega2560_ definierst du hoffentlich nirgends selbst, oder?

Natürlich nicht ;)
          ... das heißt, evtl. doch ;)
Bin ein fauler Mensch :O
Wenn Du magst, schau doch einfach mal in das Archiv von dort: 
Beitrag "Re: AVR und C++ - ein Versuch"
(Datei hal/halBase.h)

Ich verwende ein Makefile (von 1897 oder so) mit MCU-setting ...
wimre generiert von Deinem mfile-Projekt.
Ich hänge die Datei mal mit an.

Die hat mir all die Jahre treue Dienste getan und jetzt habe ich eben 
drin rum gepfuscht, um c++ auszuprobieren.
Wobei ich noch nicht weiß, welche Compiler-Schalter für c++ bei den 
kleinen Steinchen sinnvoll wären.

-ffunction-sections scheint einen nicht unerheblichen Einfluss auf die 
code-Größe zu haben. Lasse ich es weg, ist der Code gleich deutlich 
größer. Leider habe ich noch keine Erklärung zu dem Schalter gefunden.

Ansonsten denke ich, dass ich die Lösung gefunden habe. -I und -L für 
die libc völlig weg lassen. Scheinbar findet der Compiler Libs und 
Includes auch ohne Pfadangabe.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Reinhard M. schrieb:

>> Auch avr6? Das wäre die zuständige Architektur für einen ATmega2560.
>
> Klar! Auch die ;)

Gut.  Dann ist nicht ganz klar, warum der Linker sie nicht nimmt.

Schmeiß' doch mal ein -v mit in die Optionen rein, dann wird der
Compiler gesprächig (es genügt, das bei LDFLAGS zu tun).

>> _AVR_ATmega2560_ definierst du hoffentlich nirgends selbst, oder?
>
> Natürlich nicht ;)
>           ... das heißt, evtl. doch ;)

Das nicht, aber du machst so einen Quatsch:
1
#elif defined(__AVR_ATmega640__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega1281__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega2561__)
2
3
//  this processor family uses avr/io.h with real processor name
4
//  but share the hardware abstraction as ATmega640
5
#   ifndef __AVR_ATmega640__
6
#       define __AVR_ATmega640__
7
#   endif
8
#   include "halM640.h"

Merke: Namen, die mit zwei Unterstrichen beginnen, darfst du nur
dann irgendwie erzeugen, wenn die Dokumentation dich dazu anweist,
das zu tun (Beispiel: __SFR_OFFSET für Assemblerprogramme).

Nimm dir dafür einen anderen Namen.  Oder lass das #ifdef im
include-File weg oder schreib es genauso wie im Aufrufer.

> Ich verwende ein Makefile (von 1897 oder so) mit MCU-setting ...
> wimre generiert von Deinem mfile-Projekt.
> Ich hänge die Datei mal mit an.

Das passt, beim Linken wird ALL_CFLAGS mit benutzt, welches das
-mmcu enthält.  Damit ist nur nicht so ganz klar, warum der Linker
die Bibliotheken falsch sucht.

Kannst du denn normalen C-Code für einen ATmega2560 compilieren und
linken?  Also einfach mal ein helloworld.c schreiben und copilieren?

Nicht, dass deine Toolchain ein Problem hat.

> -ffunction-sections scheint einen nicht unerheblichen Einfluss auf die
> code-Größe zu haben.

Ja, zusammen mit -Wl,-gc-sections.  Genau wegen der bei C++ implizit
entstehenden zusätzlichen Methoden (aus Default-Konstruktoren und
dergleichen) wurden diese Optionen meines Wissens vor allem im GCC
vorangetrieben.

> Ansonsten denke ich, dass ich die Lösung gefunden habe. -I und -L für
> die libc völlig weg lassen. Scheinbar findet der Compiler Libs und
> Includes auch ohne Pfadangabe.

Ja, natürlich!  In einer ordentlichen Installation müssen sich die
System-Headerfiles und Bibliotheken immer selbst finden, das ist
bei diesen Multi-Architektur-Ansätzen essenziell, sonst bekommst du
die falschen reingedrückt.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Reinhard M. schrieb:

> Ich hatte Pfade für include und lib im Makefile angegeben =:O

Es müssen die richtigen Multilib-Pfade sein.  Der Compiler(-Treiber) 
weiß, wo die liegen.  Wenn du es besser weisst und per Hand angibst, 
muss das auch stimmen.

> Kaum korrigiert, moniert der compiler jetzt die richtigen libs:
> [code]/usr/local/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: skipping
> incompatible /usr/local/avr/lib/libm.a when searching for -lm

Das kann niemals die Lib für einen ATmega88 sein! dito für die 
folgenden.

Also

1) dein Installation ist Kaputt und / oder

2) du gibst die falschen Pfade per Hand an (warum?)  und / oder

3) verwendest den Treiber ohne -mmcu= und / oder

4) Verwendest avr-ld ohne Treiber und die falschen Pfade / Optionen

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Er hatte Option 2) gezogen.  Dass das ein Fehler war, hat er ja nun
selbst bemerkt. ;)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.