avr-g++ mag keine crt-dateien (crtm168.o u.Ä.) finden

[Philipp B. (philipp_burch)]

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

[Philipp B. (philipp_burch)]

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**

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

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.

[Philipp B. (philipp_burch)]

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?

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

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.

[Philipp B. (philipp_burch)]

Ah, danke für die Erklärung!