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?
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?
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 ...
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.
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:
// 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.
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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten