Forum: Compiler & IDEs Ursache Linker Error "Cannot find lib.a"


von H. K . (Gast)


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.

von Peter II (Gast)


Lesenswert?

H. K . schrieb:
> Hat jemand einen Rat, was falsch läuft?

libs werden oft ohne lib und .a hinzugefügt

-Larm_cortexM4lf_math

von Horst (Gast)


Lesenswert?

-larm_cortexM4lf_math.a
wäre korrekt. Das lib fällt beim Linkeraufruf aus unerklärlichen Gründen 
einfach weg. Ist halt wohl historisch so gewachsen.

von Horst (Gast)


Lesenswert?

Peter II schrieb:
> -Larm_cortexM4lf_math

Kleines L! Ob das a weg muss oder nicht weiß ich gerade nicht sicher

von Horst (Gast)


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

von H. K . (Gast)


Lesenswert?

Herzlichen Dank!
Das Weglassen den führenden "l" und des ".a" ->"arm_cortexM4lf_math" 
führte dazu, dass die Lib gefunden wurde. Darauf wäre ich nie gekommen!

Gruß H. K.

von Erwin D. (Gast)


Lesenswert?

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?

von H. K . (Gast)


Angehängte Dateien:

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.

von Horst (Gast)


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.

von Horst (Gast)


Lesenswert?


von H. K . (Gast)


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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.