www.mikrocontroller.net

Forum: Compiler & IDEs undefined reference to "__mulhi3"


Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Rufus T. Firefly (Gast)
Datum:

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

Autor: boggi (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

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

Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja --- ich benutze "free RTOS"

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

Autor: OldBug (Gast)
Datum:

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

Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
welche Bibliothek muss ich denn mitlinken (ich hab nen atmega128)???
(also makefile anpassen)

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: boggi (Gast)
Datum:
Angehängte Dateien:

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

Autor: Jörg Wunsch (Gast)
Datum:

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

Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??)

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das hab ich schon getan und das funktionierte auch super ...

bis ich versucht hab die c- Quellen vom freeRtos einzubinden

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: boggi (Gast)
Datum:

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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ebensoGrummel

muss ich nach dem fehler im make-File suchen

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: boggi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ,,, nachdem ich jetzt das makefile angepasst hab funzt es

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.