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?
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.
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
.
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)
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.
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.
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.
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;
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.
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
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.
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!