hi Leute ... nach dem ich angefangen hab mein Projekt von c nach c++ zu konvertieren bekomme ich jetzt noch diesen Linkerfehler ... kann jemand damit etwas anfangen ??
:
Gesperrt durch Moderator
Mal Deinen Sourcecode nach "mulhi3" durchsucht? Mal in den zum Compiler gehörenden Headerdateien danach gesucht?
ich benutze den gcc in winavr. aber weder im Winavr noch im Projekt selbst ist so etwas zu finden
Benutzt Du möglicherweise irgendwelche seltsamen Libraries? Irgendwoher muss der Symbolname ja stammen ...
naja --- ich benutze "free RTOS" und wenn ich in die Zeile des Fehler springe, dann sehe ich ne stink - normale multiplikation
Die "Stinknormale" Multiplikation liegt möglicherweise in einer nicht gelinkten Bibliothek...
welche Bibliothek muss ich denn mitlinken (ich hab nen atmega128)??? (also makefile anpassen)
Hm, merkwürdig. libc.a weist das Symbol auf. Aber Du sagtest auch etwas von C++... Tja...schwer zu sagen! Vielleicht weis Jörg da rat.
Die Definition des Symbols steht in der libgcc.a: % avr-nm /usr/local/lib/gcc/avr/3.4.1/libgcc.a |fgrep mulhi _mulhi3.o: 00000000 T __mulhi3 0000001e t __mulhi3_exit 00000004 t __mulhi3_loop 0000000c t __mulhi3_skip1 Keine Ahnung, warum der GCC diese dort nicht freiwillig mit linken will, am besten mal durch Hinzufügen von -v zu den normalen Optionen überprüfen, mit welcher Kommandozeile der Linker aufgerufen wird.
ich hab mal mein Projekt angehangen ... wär echt super, wenn mir jemand helfen könnte
Nö, sorry, nicht mit 'ner Zip-Datei. Bitte mach' Dir die Mühe, Deine Linker-Kommandozeile selbst rauszupopeln, dann helfe ich Dir.
hier der output vom Linker avr-gcc -mmcu=atmega128 -I. -g -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Iinclude/ -std=gnu99 -Wp,-M,-MP,-MT,main.o,-MF,.dep/main.elf.d tasks.o port.o queue.o list.o partest.o portheap.o main.o serial.o sleep.o lcd.o I2c.o Objects.o --output main.elf -Wl,-Map=main.map,--cref, -v -lm Reading specs from C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\specs Configured with: ../configure --prefix=/e/avrdev/install --target=avr --enable-languages=c,c++ --disable-nls --enable-win32-registry=WinAVR Thread model: single gcc version 3.3.1 C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\..\..\..\..\avr\bin\ld.exe -m avr5 -Tdata 0x800100 -o main.elf C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\..\..\..\..\avr\lib\avr5\crtm128. o -LC:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\avr5 -LC:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1 -LC:\WinAVR\bin\..\lib\gcc-lib -LC:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\..\..\..\..\avr\lib\avr5 -LC:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\..\..\..\..\avr\lib -LC:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\..\..\.. tasks.o port.o queue.o list.o partest.o portheap.o main.o serial.o sleep.o lcd.o I2c.o Objects.o -Map=main.map --cref -lm -lgcc -lc -lgcc queue.o(.text+0x4c): In function `xQueueCreate': C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/queue.c:176: undefined reference to `__mulhi3' queue.o(.text+0x90):C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/queue.c:183: undefined reference to `__mulhi3' queue.o(.text+0xe2):C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/queue.c:186: undefined reference to `__mulhi3' portheap.o(.text+0x42): In function `pvPortMalloc': C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/portheap.c:82: undefined reference to `__mulhi3' portheap.o(.text+0x5e):C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/portheap.c:84: undefined reference to `__mulhi3' portheap.o(.text+0x78):C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/portheap.c:85: more undefined references to `__mulhi3' follow make: *** [main.elf] Error 1 Da stell ich mir die frage, was bedeutet Thread model: single obwohl ich mehrere Threads habe ?? (ist das nicht auch schon nen fehler??)
portheap.o(.text+0x42): In function `pvPortMalloc': C:\Dokumente und Einstellungen\bo\Desktop\Alter Laptop\Aqua/portheap.c:82: undefined reference to `__mulhi3' Entweder passt Dein Text nicht zu den Sourcen oder ich weis nicht... In Zeile 82 ist keine Multiplikation in "portheap.c", sondern folgendes: if( xSmallBlocks[ ucBlock ].ucFull == pdFALSE ) Leider kann ich den Krempel gar nicht erst kompilieren. Vielleicht wärs auch erst mal sinnvoller, ein "Hello, World!" in C++ für den ATMega128 zu erzeugen, das würde ja zumindest schon mal die Funktionsfähigkeit des Compilers auf Deinem Host beweisen...
das hab ich schon getan und das funktionierte auch super ... bis ich versucht hab die c- Quellen vom freeRtos einzubinden
Hmm, -lgcc steht drin. Ah, __mulhi3 gibt's nur in der libgcc.a für die alten AVR-Cores. Die Bibliothek für den neuen Core (C:\WinAVR\bin\..\lib\gcc-lib\avr\3.3.1\avr5\libgcc.a) hat dieses Symbol nicht (weil die entsprechende Funktionalität hier vom Compiler mittels Hardware-Multiplikation realisiert wird). Sieht mir sehr danach aus, als wären Deine Dateien queue.o und portheap.o nicht mit -mmcu=atmega128 übersetzt worden.
die quellen haben alle das gleiche makefile ... sind also mit mmcu=128 übersetzt
OK grummel hole ich mir doch Deinen Zip-Krams. Davon abgesehen dass, wie Patrick ,,OldBug'' schon bemerkte, sich das Ganze nicht vollständig compilieren lässt (was zumindest auf die Qualität Deines Software-Setups schließen lässt, sorry), was sieht man? % gmake portheap.o avr-gcc -g -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Iinclude/ -std=gnu99 -c -o portheap.o portheap.c Wo bitte ist da ein -mmcu=atmega128 drin?
Ja, da fällt mir nur ein: es ist ein known problem, dass das WinAVR-Makefile-Template nicht 1:1 für C++ tauglich ist. Du musst da wohl CFLAGS durch CXXFLAGS ersetzen etc. pp. Pass bitte auch auf mit den substitutions, da werden irgendwie die .o-Dateien aus den Namen der .c-Dateien abgeleitet, und ${OBJS} wird im `make clean' gelöscht. Wenn Deine Eingabedateien aber nicht auf .c enden, erfolgt kein Ersatz des .{irgendwas} durch .o, sodass Deine Eingabedateien gelöscht werden... Ich weiß, dass eine auch für C++ funktionierende Lösung auf Eric's Wunschzettel für das nächste WinAVR steht.
also ,,, nachdem ich jetzt das makefile angepasst hab funzt es
Hallo! Bin noch Neuling auf diesem Gebiet. Habe dasselbe Problem wie oben beschrieben.Zudem ist eine weitere Fehlermeldung aufgetreten.Die Lösung wie o.geschrieben hilft mir leider nicht weiter.Kann mir jemand helfen? Hier deie Fehlermeldung:(NIBO 2) >floor.c:(.text.floor_writePersistent+0xc): undefined reference to `__eewr_block_m128' C:\Programme\Nibolib\lib\libnibo2.a(floor.o): In function `floor_readPersistent': >floor.c:(.text.floor_readPersistent+0xc): undefined reference to `__eerd_block_m128' >C:\Winavr-20100110\avr\lib\libc.a(vfprintf_std.o): In function `vfprintf': (.text.avr-libc+0xd4): undefined reference to `__mulhi3' >C:\Winavr-20100110\avr\lib\libc.a(vfprintf_std.o): In function `vfprintf': (.text.avr-libc+0xe4): undefined reference to `__mulhi3' make: *** [LinienBoden.elf] Error 1 Build failed with 4 errors and 0 warnings... Danke!
Henry schrieb: > Hallo! > > Bin noch Neuling auf diesem Gebiet. > Habe dasselbe Problem wie oben beschrieben.Zudem ist eine weitere > Fehlermeldung aufgetreten.Die Lösung wie o.geschrieben hilft mir leider > nicht weiter.Kann mir jemand helfen? > > Hier deie Fehlermeldung:(NIBO 2) > >>floor.c:(.text.floor_writePersistent+0xc): undefined reference to > `__eewr_block_m128' > C:\Programme\Nibolib\lib\libnibo2.a(floor.o): In function > `floor_readPersistent': >>floor.c:(.text.floor_readPersistent+0xc): undefined reference to > `__eerd_block_m128' >>C:\Winavr-20100110\avr\lib\libc.a(vfprintf_std.o): In function `vfprintf': > (.text.avr-libc+0xd4): undefined reference to `__mulhi3' >>C:\Winavr-20100110\avr\lib\libc.a(vfprintf_std.o): In function `vfprintf': > (.text.avr-libc+0xe4): undefined reference to `__mulhi3' Das bedeutet, daß beim Linken __mulhi3 nicht gefunden wird, was für einen ATmega128 nicht weiter erstaunlich ist: Diese Funktion gibt's für diesen µC nicht da 16=16*16 Multiplikation inline abgehandelt wird und nicht per libgcc-Aufruf. Du hast dein Projekt durcheinander, zB falsche Linkerflags oder kaputte Installation. Mehr ist aus deinen Infos nicht zu entnehmen.
Henry schrieb: > Bin noch Neuling auf diesem Gebiet. Bitte öffne einen neuen Thread, statt eine 7 Jahre alte Leiche auszubuddeln. Da dir die Lösung von damals ja erklärtermaßen sowieso nicht geholfen hat, ist es trotz gleicher Symptome sehr wahrscheinlich ohnehin ein anderes Problem. Im neuen Thread erzählst du dann bitte ein wenig mehr, insbesondere die kompletten Kommandozeilen, mit denen du Compiler und Linker aufrufst.