undefined reference to "__mulhi3"

[boggi (Gast)]

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

[Rufus T. Firefly (Gast)]

Mal Deinen Sourcecode nach "mulhi3" durchsucht? Mal in den zum
Compiler gehörenden Headerdateien danach gesucht?

[boggi (Gast)]

ich benutze den gcc in winavr.
aber weder im Winavr noch im Projekt selbst ist so etwas zu finden

[Rufus T. Firefly (Gast)]

Benutzt Du möglicherweise irgendwelche seltsamen Libraries?
Irgendwoher muss der Symbolname ja stammen ...

[boggi (Gast)]

naja --- ich benutze "free RTOS"

und wenn ich in die Zeile des Fehler springe, dann sehe ich ne stink -
normale multiplikation

[OldBug (Gast)]

Die "Stinknormale" Multiplikation liegt möglicherweise in einer nicht
gelinkten Bibliothek...

[boggi (Gast)]

welche Bibliothek muss ich denn mitlinken (ich hab nen atmega128)???
(also makefile anpassen)

[OldBug (Gast)]

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.

[Jörg Wunsch (Gast)]

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.

[boggi (Gast)]

ich hab mal mein Projekt angehangen ...
wär echt super, wenn mir jemand helfen könnte

[Jörg Wunsch (Gast)]

Nö, sorry, nicht mit 'ner Zip-Datei.  Bitte mach' Dir die Mühe, Deine
Linker-Kommandozeile selbst rauszupopeln, dann helfe ich Dir.

[boggi (Gast)]

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??)

[OldBug (Gast)]

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

[boggi (Gast)]

das hab ich schon getan und das funktionierte auch super ...

bis ich versucht hab die c- Quellen vom freeRtos einzubinden

[Jörg Wunsch (Gast)]

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.

[boggi (Gast)]

die quellen haben alle das gleiche makefile ... sind also mit mmcu=128
übersetzt

[Jörg Wunsch (Gast)]

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?

[boggi (Gast)]

ebensoGrummel

muss ich nach dem fehler im make-File suchen

[Jörg Wunsch (Gast)]

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.

[boggi (Gast)]

also ,,, nachdem ich jetzt das makefile angepasst hab funzt es

[Henry (Gast)]

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!

[Johann L. (gjlayde)]

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.

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

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.