Ursache Linker Error "Cannot find lib.a"

Gast #4676531
Lesenswert?

Guten Morgen,

Ich benutze DAVE zum programmieren von CortexM4-Controllern von 
Infineon.
Seit gestern versuche ich die ARM-Mathematik-bib 
"libarm_cortexM4lf_math.a" einzubinden, ohne Erfolg.

Es ist mir gelungen, DAVE (basiert auf Eclipse) mitzuteilen, wo die 
.h-Dateien zu finden sind; nachdem ich 
"${ARM_GCC_HOME}\lib\CMSIS\Include" zu den Directories unter "ARM-GGC C 
Compiler" eingefügt habe, waren alle .h-Dateien der DSP-lib in der 
Baumansicht aufgelistet und der Hilfecontext funktionierte.

Unter "ARM-GCC Linker" habe ich o.g. "libarm_cortexM4lf_math.a" in dem 
"-l"-Feld eingefügt. In der "-L"-Sektion habe ich den Pfad zu der Datei 
über "${ARM_GCC_HOME}\lib\CMSIS\Lib\GCC" angegeben.

Es kam eine Fehlermeldung vom Linker, dass die lib nicht gefunden wurde. 
Versuchsweise habe ich den Pfad auch mal direkt angegeben, die 
Fehlermeldung kam erneut.
Im Makefile wird der Pfad korrekt eingetragen; wenn ich die Pfadangabe 
dort herauskopiere und in ein Explorerfenster eingebe, komme ich direkt 
in das Verzeichnis, wo die Datei liegt.

Hat jemand einen Rat, was falsch läuft?

Hat die Fehlermeldung evtl. eine andere Ursache?

H.K.
Gast #4676546
Lesenswert?

-larchive
--library=archive
Add archive file archive to the list of files to link. This option may 
be used any number of times. ld will search its path-list for 
occurrences of libarchive.a for every archive specified.

Also ohne .a wohl auch
Gast #4676692
Lesenswert?

Folgende Einstellung lässt den GCC durchlaufen. Allerdings hat die Lib 
wohl ein Problem mit der FPU, sobald der erste Befehl aus der ARM-Lib 
aufgerufen wird, landet der Controller in einer 
Exception-Behandlungsroutine, aber daran ist der Linker unschuldig.
Angehängte Dateien:
Gast #4676711
Lesenswert?

Erwin D. schrieb:
> H. K . schrieb:
>> Das Weglassen den führenden "l" und des ".a"
>
> Sicher? Hast du wirklich nur das "l" weggelassen oder das "lib" am
> Anfang?

Er meint wahrscheinlich das l was ich geschrieben hatte. Das -l kommt 
aber von dem GUI-Kram.

H. K . schrieb:
> llerdings hat die Lib
> wohl ein Problem mit der FPU, sobald der erste Befehl aus der ARM-Lib
> aufgerufen wird, landet der Controller in einer
> Exception-Behandlungsroutine,

Hast du die entsprechenden Bits gesetzt, dass die FPU auch an ist?
Ansonsten noch darauf achten, dass deine Floats nicht unaligned im 
Memory liegen, sonst gehts auch nicht.
Gast #4676982
Lesenswert?

>Das Weglassen den führenden "l" und des ".a" ->"arm_cortexM4lf_math"
Das muss heißen:
"Das Weglassen des führenden "lib" und des ".a" 
->"arm_cortexM4lf_math"..."

>Hast du die entsprechenden Bits gesetzt, dass die FPU auch an ist?

Das wird vom Startup-Script automatisch eingerichtet, sobald 
__FPU_PRESENT definiert ist.

Ich weiß nicht, woran es gelegen hat, das der MC ständig in der 
Exceptionroutine gelandet ist.
Ich habe dann herausgefunden, dass er das auch dann macht, wenn alle 
FPU-betreffenden Befehle auskommentiert sind.
Seit ich ein neues Projekt aufgesetzt habe und die FPU-Optionen auf 
"mfloat-abi=hard" gestellt sind, läuft das Programm auf dem Evalboard 
durch.
Die Ergebnisse der arm_sin_f32 sind korrekt.

Testweise habe eine arm_rfft_f32 über 1024 Werte laufen lassen.
Laut dem Cycle-Counter hat der MC dafür nur knapp 69k cycles gebraucht,
die arm_sin_f32 benötigt ca. 140.

Die Lib scheint also zu laufen...

Danke für die Hilfe,

H. K.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren