ARM Linker findet Symbol in Library nicht

[Tom (Gast)]

Hallo miteinander

Ich entwickle gerade auf einem TMS320F28388D von Texas Instruments. Auf 
dem Chip befindet sich ein Arm Cortex Prozessor auf dem ich ein Teil 
meines Projekts implementiere.

Seit gestern habe ich Probleme, meinen Code für den Cortex zu 
compilieren. Ein Widerherstellen des Codes zu einem früheren commit hat 
bisher nichts gebracht, es scheint ein Problem mit dem Linker zu geben.

Zusammenfassend sieht die Situation so aus:

1. Beim Compilieren kriege ich folgende Fehlermeldungen (s. auch 
issue_1.png):

Description  Resource  Path  Location  Type
no source files, nothing to do  ccard_tcp_interface       C/C++ Problem
Symbol 'Ethernet_receiveISR' could not be resolved  main_tcp_interface_lwip.c  /ccard_tcp_interface  line 615  Semantic Error
Symbol 'Ethernet_transmitISR' could not be resolved  main_tcp_interface_lwip.c  /ccard_tcp_interface  line 614  Semantic Error

Die Symbole "Ethernet_receiveISR" und "Ethernet_transmitISR" sollten 
aber in der library "driverlib_cm.lib" definiert sein, das kann ich mit 
dem folgenden Kommando verifizieren:

nm ~/ti/C2000Ware_3_04_00_00_Software/driverlib/f2838x/driverlib_cm/ccs/Debug/driverlib_cm.lib | grep Ethernet_rec

00000001 T Ethernet_receiveISR
00000001 T Ethernet_receivePacketCallback

nm ~/ti/C2000Ware_3_04_00_00_Software/driverlib/f2838x/driverlib_cm/ccs/Debug/driverlib_cm.lib | grep Ethernet_tran

00000001 T Ethernet_transmitISR

In Eclipse habe ich die library und deren Pfad explizit für den Linker 
angegeben, siehe auch "issue_2.png".

In der Build Konsole scheint der Fehler an folgender Stelle auzutreten:

Building target: "enet_lwip_cm.out"
Invoking: ARM Linker
"/home/dvarx/ti/ccs1030/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=none -me -O0 --opt_for_speed=0 --define=_FLASH --define=ccs -g --diag_warning=225 --gen_func_subsections=on --abi=eabi --ual -n -z -m"enet_lwip_cm.map" --heap_size=0 --stack_size=2048 -i"/home/dvarx/ti/ccs1030/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/lib" -i"/home/dvarx/ti/C2000Ware_3_04_00_00_Software/driverlib/f2838x/driverlib_cm/ccs/Debug" -i"/home/dvarx/ti/ccs1030/ccs/tools/compiler/ti-cgt-arm_20.2.4.LTS/include" -i"/home/dvarx/ti/ccs1030/ccs/tools/compiler" -i"/home/dvarx/ti/C2000Ware_3_04_00_00_Software/driverlib/f2838x/driverlib_cm/ccs/Debug" --reread_libs --warn_sections --xml_link_info="enet_lwip_cm_linkInfo.xml" --rom_model -o "enet_lwip_cm.out" "./comm_interface.obj" "./f2838xif.obj" "./fs.obj" "./httpd.obj" "./lwiplib.obj" "./main_tcp_interface_lwip.obj" "./pinout.obj" "./startup_ccs.obj" "./ustdlib.obj" "../2838x_flash_lnk_cm_lwip.cmd"  -l"/home/dvarx/ti/C2000Ware_3_04_00_00_Software/driverlib/f2838x/driverlib_cm/ccs/Debug/driverlib_cm.lib" -l"/home/dvarx/ti/C2000Ware_3_04_00_00_Software/driverlib/f2838x/driverlib_cm/ccs/Debug/driverlib_cm.lib" -llibc.a 
>> ERROR: no source files, nothing to do
Finished building target: "enet_lwip_cm.out"

Die Fehlermeldung des Linkers verstehe ich nicht. Der Linker muss ja an 
sich keine source files kompilieren sondern eben nur linken, weshalb 
beschwert er sich dann über fehlende source files?

[DerEinzigeBernd (Gast)]

Liegt denn die Library mit ihrem Namen *.lib in einem vom gcc-Linker 
verständlichen Format vor? Die Erweiterung ist ungewöhnlich, der 
gcc-Linker nutzt üblicherweise *.a

Und ist es nicht so, daß der Linker beim Argument -l automatisch "lib" 
vor den angegebenen Namen und ".a" dahinter setzt?

Ich meine schon gesehen zu haben, daß um "libm.a" zu verwenden nur "-lm" 
angegeben werden muss.

[Rolf M. (rmagnus)]

Warum linkst du zweimal an die driverlib_cm.lib?

DerEinzigeBernd schrieb:
> Ich meine schon gesehen zu haben, daß um "libm.a" zu verwenden nur "-lm"
> angegeben werden muss.

Ja, so ist es normalerweise. Auch haben die Objekt-Dateien eigentlich 
die Endung .o und nicht .obj. Aber ist das überhaupt der GNU-Linker, der 
hier verwendet wird?

[Klaus W. (mfgkw)]

*.lib und *.obj hört sich eher nach Windowsumgebung an.

Sicher, daß du die dazu linken willst?

[Tom (Gast)]

Hallo miteinander

Wie sich herausstellte war das Problem ein `-n` Flag dass im Compiler 
gesetzt wurde. Dies hatte zur Folge dass der Compiler nur Assembly Code 
`.asm` und kein Objektcode `.obj` erzeugt hat.

Damit konnte der Linker auch nichts linken. Nachdem ich das Flag 
deaktiviert habe funktioniert alles wieder.