mikrocontroller.net

Forum: Compiler & IDEs avr-g++ mag keine crt-dateien (crtm168.o u.Ä.) finden


Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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**

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, danke für die Erklärung!

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.