it-swarm.com.de

LNK2019: Nicht aufgelöstes externes Symbol _main in Funktion ___tmainCRTStartup referenziert

Ich habe den folgenden Fehler LNK2019: nicht aufgelöstes externes Symbol _main in Funktion ___tmainCRTStartup referenziert, 

Es gibt viele Threads, die sich auf diesen Fehler beziehen, aber keine dieser Lösungen hat für mich funktioniert. Und keiner hat erklärt, warum dieser Fehler hier ist.

Ich habe es versucht:

habe es nicht versucht und vermuten, dass diese auch nicht funktionieren werden:

warum erhalte ich diesen Fehler und was ist die Lösung?

23
forest.peterson

Was ist dein Projekttyp? Wenn es sich um ein "Win32-Projekt" handelt, sollte Ihr Einstiegspunkt (w)WinMain sein. Wenn es sich um ein "Win32-Konsolenprojekt" handelt, sollte es (w)main sein. Der Name _tmain ist #definiert und ist entweder main oder wmain, je nachdem, ob UNICODE definiert ist oder nicht.

Wenn es sich um eine DLL handelt, dann DllMain.

Der Projekttyp ist unter Projekteigenschaften, Linker, System, Subsystem zu sehen. Es würde entweder "Konsole" oder "Windows" sagen.

Beachten Sie, dass der Name des Einstiegspunkts davon abhängt, ob UNICODE definiert ist oder nicht. In VS2008 ist dies standardmäßig definiert.

Der richtige Prototyp für main ist entweder

int _tmain(int argc, _TCHAR* argv[])

oder 

int _tmain()

Stellen Sie sicher, dass es einer von diesen ist.

BEARBEITEN:

Wenn Sie einen Fehler in _TCHAR erhalten, platzieren Sie eine

#include <tchar.h>

Wenn Sie der Meinung sind, dass das Problem mit einem der Header zusammenhängt, gehen Sie zu den Eigenschaften der Datei mit main () und aktivieren Sie unter Vorprozessor die Erzeugung der vorverarbeiteten Datei. Dann kompilieren. Sie erhalten eine Datei mit dem gleichen Namen und der Erweiterung .i. Öffnen Sie es und sehen Sie, ob der main () - Funktion etwas Unangenehmes passiert ist. Theoretisch kann es Schimpfwörter geben ...

EDIT2:

Wenn UNICODE definiert ist (Standardeinstellung), erwartet der Linker, dass der Einstiegspunkt wmain () und nicht main () ist. _tmain hat den Vorteil, dass es UNICODE-agnostisch ist - es wird entweder in main oder in wmain übersetzt.

Vor einiger Zeit gab es einen Grund, einen ANSI-Build und einen Unicode-Build beizubehalten. Die Unicode-Unterstützung war in Windows 95/98/Me sehr unvollständig. Die primären APIs waren ANSI, und Unicode-Versionen waren hier und dort vorhanden, jedoch nicht durchgängig. Der VS-Debugger hat auch Probleme beim Anzeigen von Unicode-Zeichenfolgen. In den NT-Kernel-Betriebssystemen (das ist Windows 2000/XP/Vista/7/8/10) ist die Unicode-Unterstützung primär und ANSI-Funktionen werden hinzugefügt. Seit VS2005 ist Unicode der Standard bei der Projekterstellung. Das heißt - wmain. Sie konnten nicht denselben Namen des Einstiegspunkts beibehalten, da die Parametertypen unterschiedlich sind. _TCHAR ist #definiert und ist entweder char oder wchar_t. _Tmain ist also entweder main (int argc, char ** argv) oder wmain (int argc, wchar_t ** argv).

Der Grund, warum Sie irgendwann einen Fehler bei _tmain erhalten haben, war wahrscheinlich, dass Sie den Typ von argv nicht in _TCHAR** geändert haben.

Wenn Sie nicht planen, ANSI (wahrscheinlich nicht) zu unterstützen, können Sie Ihren Einstiegspunkt als neu formulieren

int wmain(int argc, wchar_t *argv[])

und entfernen Sie die tchar.h-Include-Zeile.

28
Seva Alekseyev

Da es noch nicht erwähnt wurde, war dies die Lösung für mich:

Ich hatte diesen Fehler mit einer DLL, nachdem ich eine neue Konfiguration für mein Projekt erstellt hatte. Ich musste zu Project Properties -> Configuration Properties -> General gehen und den Configuration Type in Dynamic Library (.dll) ändern.

Wenn Sie nach dem Ausprobieren noch Probleme haben, sollten Sie überprüfen, ob der Konfigurationstyp Ihrem Projekt entspricht. Wenn es nicht richtig eingestellt ist, sucht der Compiler nach dem falschen Hauptsymbol. In meinem Fall suchte es nach WinMain anstelle von DllMain.

6
Dizzyspiral

Ich habe diese Fehlermeldung erhalten, als ich vorkompilierte Header in einem Konsolenanwendungsprojekt deaktivieren und die Headerdatei stdafx.h entfernen wollte

Um dies zu beheben, gehen Sie zu Ihren Projekteigenschaften -> Linker -> SubSystem Und ändern Sie den Wert in Not Set .

Verwenden Sie in Ihrer Hauptklasse die standardmäßige C++ - Hauptfunktion protoype, die bereits von anderen erwähnt wurde:

int main(int argc, char** argv)
3

Wenn Sie ein "Win32-Projekt" definiert haben und ein WinMain definiert ist und Ihre SubSystem-Linker-Einstellung auf WINDOWS gesetzt ist, können Sie diesen Linker-Fehler trotzdem erhalten, falls jemand die "Zusätzliche Optionen" in den Linker-Einstellungen auf "/ SUBSYSTEM: CONSOLE" setzt wie diese zusätzliche Einstellung wird der tatsächlichen SubSystem-Einstellung vorgezogen.

2
TomSmartBishop

Ich hatte dieses Problem vor Minuten. Es verschwand, als ich der Definition von main () 'extern' C '' hinzufügte. 

Seltsamerweise ist ein anderes einfaches Programm, das ich gestern geschrieben habe, fast identisch, hat nicht das externe "C", aber noch ohne diesen Linker-Fehler kompiliert. 

Dies lässt mich denken, dass das Problem eine subtile Einstellung ist, die tief in einem Konfigurationsdialogfeld zu finden ist, und dass ein externes "C" das zugrunde liegende Problem nicht wirklich löst, sondern nur oberflächlich funktioniert.

1
DarenW

Ich hatte diesen Fehler, als ich versehentlich den Wmain in einen Namespace stellte. wmain sollte sich in keinem Namespace befinden. Außerdem hatte ich eine Hauptfunktion in einer der Bibliotheken, die ich verwendete, und VS übernahm die Hauptfunktion von dort, was sie noch fremder machte.

1
Pagefault

Ich finde das, wenn ich die Option .__ wähle. Projekt-> Eigenschaften-> Linker-> System-> SubSystem-> Console (/ subsystem: console), Stellen Sie dann sicher, dass die Funktion ____.int.tmain (int argc, _TCHAR * argv ]) {return 0} das Kompilieren, Verknüpfen und Laufen ist in Ordnung;

1
Shania

Ich hatte dies aus einem interessanten Grund auch in Visual Studio 2015. Einfach hier hinzufügen, falls es jemand anderem passiert.

Ich hatte bereits eine Anzahl von Dateien im Projekt und ich fügte eine weitere hinzu, die eine Hauptfunktion hatte. Als ich die Datei anfangs hinzufügte, machte ich einen Tippfehler in der Erweiterung (.coo statt .cpp). Ich habe das korrigiert, aber als ich fertig war, bekam ich diesen Fehler. Es stellte sich heraus, dass Visual Studio intelligent war und beim Hinzufügen der Datei entschieden wurde, dass es sich bei der ursprünglichen Erweiterung nicht um eine Quelldatei handelt.

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Datei, wählen Sie Eigenschaften -> Allgemein -> ItemType und setzen Sie sie auf "C/C++ - Compiler", um das Problem zu beheben.

0
Sebastian K

diese main funktioniert sowohl in Linux als auch in Windows - fand es durch Versuch und Irrtum und Hilfe von anderen. Kann also nicht erklären, warum es funktioniert, es funktioniert einfach int main(int argc, char** argv)

kein tchar.h erforderlich

und hier ist die gleiche Antwort in Wikipedia Hauptfunktion

0
forest.peterson

In meinem Fall liegt es daran, dass ich die Dateien stdafx.h und targetver.h im Abschnitt Header Files versehentlich entfernt (nicht gelöscht) habe.

Fügen Sie diese Dateien wieder zu Header Files hinzu und das Problem ist gelöst.

Ich hatte diese:

#pragma comment( linker, "/entry:\"mainCRTStartup\"" ) // set the entry point to be main()

Ich muss nur das kommentieren (durch Voranstellen von //) und es ist gut.

0
Hendy Irawan

Ich hatte das Problem schon einmal, aber es wurde gelöst. Das Hauptproblem war, dass ich versehentlich die int main () - Funktion buchstabiere. Anstatt int main () zu schreiben, schrieb ich int mian () .... Prost!

0

 Screen snapshot Visual Studio 2015

Stellen Sie das System gemäß den vorherigen Vorschlägen auf Konsole ein. Nur musste auch der Zeichensatz in Unicode geändert werden, siehe Snapshot von Visual Studio 2015.

0
LastBlow