[C++] Linker-Probleme (MSVC++7.1)

S

Spacy

Gast
Hi!

Ich habe ein paar Linker-Probleme mit einer ziemlich großen Anwendung, an der ich ein bischen rumwerkle (VBA - VisualBoyAdvance GBA Emulator):
nafxcw.lib(afxmem.obj) : warning LNK4006: '"void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)' bereits in 'LIBCMT.lib(new.obj)' definiert; zweite Definition wird ignoriert
nafxcw.lib(afxmem.obj) : warning LNK4006: '"void __cdecl operator delete(void *)" (??3@YAXPAX@Z)' bereits in 'LIBCMT.lib(delete.obj)' definiert; zweite Definition wird ignoriert
nafxcw.lib(afxmem.obj) : warning LNK4006: '"void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z)' bereits in 'LIBCMT.lib(new2.obj)' definiert; zweite Definition wird ignoriert
nafxcw.lib(afxmem.obj) : warning LNK4006: '"void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z)' bereits in 'LIBCMT.lib(delete2.obj)' definiert; zweite Definition wird ignoriert

Mir sagt das soviel, dass MFC und und die Multi-Threaded Runtime von MSVC++ beide new und delete definieren, aber irgendwie kann das doch nicht sein, weil man ja sonst kein Programm schreiben könnte, das MFC benutzt.

Ich habe das problem momentan mit der FORCE Linker-Option umgangen, aber das ist gewiss nicht die beste Option.
 
Habe ich soeben versucht, ergibt aber leider nur unzählige Meldungen über nicht verwiesenen Funktionen...
 
Ich glaube man muss da irgendwie an nem anderen Punkt ansetzen, normalerweise dürfte es ja kein Problem darstellen, genau diesen beiden Libraries in einem Programm zu verwenden.


EDIT:
Sowas, jetzt ist das auf einmal ein Doppelpost geworden ^_^"
 
Zuletzt bearbeitet:
Naja, es sind ja nur warnings, sieht nicht schön aus, ist aber auch net schlimm.
 
Natürlich ist das schlimm, das ist eine Verletzung der ODR (One Definition Rule). Das mit /force zu ignorieren sollte man nun wirklich nicht tun. Genau genommen ist es jetzt kein gültiges C++ Programm mehr.

Gehört new2.obj zur VC++ Runtime? Ist beim VC++ sowas wie c++filt dabei? Damit kannst Du den Namen demanglen und erstmal schauen, welcher Operator new / delete da nun genau angemeckert wird.

Hast Du vielleicht die Multi-Threaded-Runtime mit nicht-threaded Bibiotheken gemixt oder sowas?
 
Zuletzt bearbeitet:
7H3 N4C3R schrieb:
Natürlich ist das schlimm, das ist eine Verletzung der ODR (One Definition Rule). Das mit /force zu ignorieren sollte man nun wirklich nicht tun. Genau genommen ist es jetzt kein gültiges C++ Programm mehr.

Gehört new2.obj zur VC++ Runtime? Ist beim VC++ sowas wie c++filt dabei? Damit kannst Du den Namen demanglen und erstmal schauen, welcher Operator new / delete da nun genau angemeckert wird.

Hast Du vielleicht die Multi-Threaded-Runtime mit nicht-threaded Bibiotheken gemixt oder sowas?

Das hab ich mir auch gedacht, dass das keine gute Methode ist.

new2.obj gehört zur VC Runtime. Was ist c++filt? Was heißt "demangeln"?

Wenn ich die MultiThreaded mit Non-Threaded runtimes gemixt hätte, müssten da doch Konflikte zwischen LIBC.lib und LIBCMT.lin auftreten.


Würde es helfen, wenn ich den Source Code einfach mal poste/hochlade? Ist sowieso OpenSource, vielleicht kennt sich jemand besser mit der Microsoft-IDE aus.
 
Der Compiler betreibt Name-Mangling, um C++ Namen in C Namen umzuwandern. Dabei kommt dann sowas raus:
"void * __cdecl operator new(unsigned int) (??2@YAPAXI@Z)"
Mit demangling macht man den Vorgang rückgängig und bekommt einen verwertbaren Namen zurück. Ein Standardprogramm, dass das unter Linux macht ist c++filt. Für VC++ sollte es eigentlich ein Pendant geben.

Ist sonst vielleicht Unicode / Non-Unicode irgendwie gemixt? Ich hab kein VC++, von daher würden mir die Projekt-Files (wo letztendlich der Wurm drin sein wird), nicht viel helfen. Vielleicht aber jemand anderes?
 
Hm, also auf den ersten Blick finde ich kein c++filt Pendant, normalerweise braucht das ja auch kein Entwickler, wenn alles funzt.

Also ich habe eben mal ein neues MFC Projekt gestartet. Das hat fast die selbe Konfiguration wie meine Anwendung: MFC-Statisch, MultiThreded-Statisch, selbe Präprozessor-Definitionen.

Ich glaube, es hat vielelicht was damit zu tun, dass irgendwo mit den headern gemurkst wurde.

Egal, im Anhang befidnet sich das Projekt für Visual C++ .NET 2003 (7.1).

Wer mir hilft, die blöden 4 Warnungen zu entfernen kommt selbstverständlich in die Credits ;)
http://magicstone.de/spacy/VBA/VBA_WIP_S176.7z



Es wurd wirklich Zeit, dass ich auf Linux umsteige :freak:
 
Schau dir mal das hier an.
Ich probiers grad aus, mein Rechner ist net der schnellste auf Arbeit.
Wenns geklappt hat, soll ich dir das mailen?
PS: Aktueller Stand: keine Fehler im Debug Modus, haufenweise warnings im Release Modus.
 
Zuletzt bearbeitet:
Aha, das scheint genau das zu sein, was ich suche.

Ich probier das gleich mal aus...

Schonmal vielen Dank :D

Ich freu mich so ^^
 
Nochmal Update:
Debug Modus läuft super.
Dasselbe Prinzip mit dem Release oder Optimize Modus klappt nicht.
Dann haut die msvcrt.lib dazwischen, obwohl ich die explizit ignoriert habe.
 
Also bei mir geht alles hervorragend jetzt. Vielen Dank. Bist in den Credits :D

Ich kontne das Problem zwar nicht über den Quellcode beheben (habe alles durchsucht, aber es steht überall stdafx VOR allem anderen), aber immerhin über die Linkereinstellungen.


Meinen nächsten Release gibt es dann bald auf http://www.ngemu.com/forums/showthread.php?p=870433
 
Zurück
Oben