Hallo zusammen, ich habe heute endlich mal das Update auf die avr-libc 1.7.0 vorgenommen. Installiert war 1.6.5 aus dem Ubuntu-Repository. 1.7.0 gibt es da anscheinend noch nicht, daher habe ich mir den Source geholt. configure und make (install) liefen auch ohne zu murren durch. Das erste Problem war dann erstmal, dass die alte Version ihre includes und libs in /usr/lib/avr geschmissen hat, wogegen make install lieber nach /usr/local/avr installiert. Nach dem anpassen der entsprechenden Verzeichnisse (Ich verwende code::blocks mit dem AVR-GCC-Plugin) funktionierte das Kompilieren ohne Probleme. Aus irgendeinem Grund will der Linker (avr-g++) nun aber keine Bauteilabhängigen Bibliotheken mehr finden, in meinem Fall die crtm168.o, bzw. crtm168p.o. Der Aufruf sieht so aus: avr-g++ -L/usr/local/avr/lib -o default/kassenblinkersteuerung.elf default/src/blink.o default/src/brightness.o default/src/bus.o default/src/init.o default/src/main.o -mmcu=atmega168p -Wl,-Map=default/kassenblinkersteuerung.elf.map,--cref Die benötigte Datei ist auch vorhanden: $ find /usr/local/avr -name 'crtm168p.o' /usr/local/avr/lib/avr5/crtm168p.o Interessanterweise geht es nichtmal wenn ich die Datei explizit angebe: $ avr-g++ -l/usr/local/avr/lib/avr5/crtm168p.o -L/usr/local/avr/lib -o default/kassenblinkersteuerung.elf default/src/blink.o default/src/brightness.o default/src/bus.o default/src/init.o default/src/main.o -mmcu=atmega168p -Wl,-Map=default/kassenblinkersteuerung.elf.map,--cref /usr/lib/gcc/avr/4.3.4/../../../avr/bin/ld: crtm168p.o: No such file: No such file or directory strace meint dazu folgendes (Nur die Zeilen mit crtm168p): access("/usr/lib/gcc/avr/4.3.4/avr5/crtm168p.o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.3.4/../../../avr/lib/avr/4.3.4/avr5/crtm168p. o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.3.4/../../../avr/lib/avr5/crtm168p.o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.3.4/crtm168p.o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.3.4/../../../avr/lib/avr/4.3.4/crtm168p.o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.3.4/../../../avr/lib/crtm168p.o", R_OK) = -1 ENOENT (No such file or directory) Wo liegt hier das Problem? Danke und Gruss, Philipp
Update: Wenn ich als /usr/lib/avr/lib einen symbolischen Link nach /usr/local/avr/lib setze funktioniert es. Das ist aber auch mehr ein Hack als etwas anderes, denn die -L-Option wird ja nicht aus Jux und Tollerei verwendet... **confused**
Deine ./configure-Scripts musst du zwischen AVR-binutils, AVR-GCC und avr-libc alle mit dem gleichen --prefix aufrufen. Musst dich da schon entscheiden, ob du /usr/local haben willst oder /usr.
Achsoooo, danke. Jetzt geht's. Trotzdem finde ich es interessant, dass sich der Linker weigert, die angegebene Datei zu verwenden. Werden da trotz Argument irgendwelche Standardeinstellungen verwendet?
Philipp Burch schrieb: > Trotzdem finde ich es interessant, dass sich der Linker weigert, die > angegebene Datei zu verwenden. Du hast die -l Option einfach nur nicht verstanden. Die C runtime ist keine Bibliothek, schon dehsalb ist eine -l Option dafür unsinnig. Wenn schon, hättest du mit -nostartfiles dem Compiler sagen müssen, dass er die Standard-runtime-Objekte nicht benutzen soll, und dann explizit dein crtm168p.o als erstes zu linkendes Objekt angeben müssen. Die -l Option funktioniert so: -lfoo sucht (im eingebauten oder ggf. durch -L Optionen erweiterten Pfad) nach einer Bibliothek mit dem Namen libfoo.a und versucht dann, aus dieser Bibliothek Objektmodule zu linken, die derzeit ungelöste globale Symbole ("global undefined") auflösen würden. Sollten dabei weitere derartige Symbole entstehen, wird die gleiche Bibliothek erneut durchsucht, danach wird mit der in der (Kommandozeilen-)Reihenfolge nächsten fortgefahren.
Ah, danke für die Erklärung!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.