web-dev-qa-db-fra.com

LNK2019: symbole externe non résolu _main référencé dans la fonction ___tmainCRTStartup

J'ai l'erreur suivante LNK2019: symbole externe non résolu _main référencé dans la fonction ___tmainCRTStartup, 

Il y a beaucoup de discussions relatives à cette erreur, mais aucune de ces solutions n'a fonctionné pour moi. Et, personne n'a expliqué pourquoi cette erreur est ici.

J'ai essayé:

n'ont pas essayé et soupçonnent que cela aussi ne fonctionnera pas:

pourquoi ai-je cette erreur et quelle est la solution?

c++windowsvisual-studio-2008windows-7lnk2019
23
forest.peterson

Quel est votre type de projet? S'il s'agit d'un "projet Win32", votre point d'entrée doit être (w)WinMain. S'il s'agit d'un "Projet de console Win32", il devrait alors s'agir de (w)main. Le nom _tmain est #defined pour être main ou wmain selon que UNICODE est défini ou non.

Si c'est une DLL, alors DllMain.

Le type de projet est visible dans les propriétés du projet, Éditeur de liens, Système, Sous-système. Il dirait soit "Console" ou "Windows".

Notez que le nom du point d'entrée varie selon que UNICODE est défini ou non. Dans VS2008, il est défini par défaut.

Le prototype approprié pour main est soit

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

ou 

int _tmain()

Assurez-vous que c'est l'un de ceux-là.

MODIFIER:

Si vous obtenez une erreur sur _TCHAR, placez un

#include <tchar.h>

Si vous pensez que le problème concerne l'un des en-têtes, accédez aux propriétés du fichier avec main (), et sous Préprocesseur, activez la génération du fichier prétraité. Puis compiler. Vous obtiendrez un fichier portant le même nom et une extension .i. Ouvrez-le et voyez si quelque chose de désagréable est arrivé à la fonction main (). Il peut y avoir des #defines voyous en théorie ...

EDIT2:

Avec UNICODE défini (valeur par défaut), l’éditeur de liens s’attend à ce que le point d’entrée soit wmain () et non main (). _tmain a l’avantage d’être UNICODE-agnostique - c’est-à-dire main ou wmain.

Il y a quelque temps, il y avait une raison de conserver à la fois une version ANSI et une version Unicode. La prise en charge Unicode était cruellement incomplète dans Windows 95/98/Me. Les principales API étaient ANSI et les versions Unicode existaient ici et là, mais pas de manière généralisée. De plus, le débogueur VS a eu du mal à afficher les chaînes Unicode. Dans les systèmes d’exploitation du noyau NT (sous Windows 2000/XP/Vista/7/8/10), la prise en charge Unicode est principale et les fonctions ANSI sont ajoutées en haut. Ainsi, depuis VS2005, la valeur par défaut lors de la création du projet est Unicode. Cela signifie - wmain. Ils n'ont pas pu conserver le même nom de point d'entrée car les types de paramètres sont différents. _TCHAR est # défini comme étant char ou wchar_t. Donc, _tmain est soit principal (int argc, car ** argv) ou wmain (int argc, wchar_t ** argv).

La raison pour laquelle vous obteniez une erreur à _tmain à un moment donné était probablement parce que vous n'avez pas changé le type de argv en _TCHAR**.

Si vous n’avez pas l’intention de prendre en charge la norme ANSI (probablement pas), vous pouvez reformuler votre point d’entrée en tant que

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

et supprimez la ligne tchar.h include.

28
Seva Alekseyev

Parce que cela n'a pas encore été mentionné, c'était la solution pour moi:

J'ai eu cette erreur avec un DLL après avoir créé une nouvelle configuration pour mon projet. Je devais aller à Project Properties -> Configuration Properties -> General et changer le Configuration Type en Dynamic Library (.dll).

Par conséquent, si vous rencontrez toujours des problèmes après avoir tout essayé, vérifiez si le type de configuration correspond à vos attentes. S'il n'est pas défini correctement, le compilateur recherchera le mauvais symbole principal. Dans mon cas, il cherchait WinMain au lieu de DllMain.

6
Dizzyspiral

J'ai eu cette erreur alors que j'essayais de désactiver les en-têtes précompilés dans un projet d'application console et de supprimer le fichier d'en-tête stdafx.h

Pour résoudre ce problème, allez dans les propriétés de votre projet -> Éditeur de liens -> Sous-système Et remplacez la valeur par Non défini

Dans votre classe principale, utilisez le prototype de fonction principale C++ standard déjà mentionné:

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

Si vous avez un "projet Win32" + défini un WinMain et que votre paramètre de l'éditeur de liens du sous-système est défini sur WINDOWS, vous pouvez toujours obtenir cette erreur de l'éditeur de liens si quelqu'un définit les "Options supplémentaires" dans les paramètres de l'éditeur de liens à comme ce paramètre supplémentaire est préférable au paramètre de sous-système actuel.

2
TomSmartBishop

J'ai eu ce problème il y a quelques minutes. Cela a disparu lorsque j'ai ajouté 'extern "C" à la définition de main (). 

Bizarrement, un autre programme simple que j’ai écrit hier est presque identique, n’a pas l’extérieur "C", pourtant compilé sans cette erreur de l'éditeur de liens. 

Cela me fait penser que le problème est un paramètre subtil qui se trouve en profondeur dans un dialogue de configuration, et que "extern" C "ne résout pas vraiment le problème sous-jacent, mais qu'il fait fonctionner les choses de manière superficielle.

1
DarenW

J'ai eu cette erreur en mettant accidentellement le wmain dans un espace de noms. wmain ne doit être dans aucun espace de noms. De plus, j'avais une fonction principale dans l'une des bibliothèques que j'utilisais, et VS a pris la principale, ce qui la rendait encore plus étrangère.

1
Pagefault

Je trouve que quand je choisis l'option de Projet-> Propriétés-> Éditeur de liens-> Système-> Sous-système-> Console (/ subsystem: console), Et assurez-vous d'inclure La fonction: Int _tmain (int argc, _TCHAR * argv [ ]) {return 0} toute la compilation, la création de liens et l’exécution seront satisfaisantes;

1
Shania

Cela s'est produit dans Visual Studio 2015 également pour une raison intéressante. Ajoutez-le simplement ici au cas où cela arriverait à quelqu'un d'autre.

J'avais déjà un certain nombre de fichiers dans le projet et j'en ajoutais un autre qui aurait une fonction principale. Cependant, lorsque j'ai initialement ajouté le fichier, j'ai créé une faute de frappe dans l'extension (.coo au lieu de .cpp). J'ai corrigé cela mais quand j'ai eu fini j'ai eu cette erreur. Il s'est avéré que Visual Studio était intelligent et lorsque le fichier a été ajouté, il a décidé qu'il ne s'agissait pas d'un fichier source en raison de l'extension initiale.

En cliquant avec le bouton droit de la souris sur le fichier dans l'explorateur de solutions, en sélectionnant Propriétés -> Général -> ItemType et en le définissant sur "Compilateur C/C++", le problème a été résolu.

0
Sebastian K

this main fonctionne à la fois sous linux et sous windows - l’a trouvé par essais et erreurs et l’aide d’autres personnes, donc je ne peux pas expliquer pourquoi cela fonctionne, c’est le cas int main(int argc, char** argv)

non tchar.h nécessaire

et voici la même réponse dans Wikipedia Fonction principale

0
forest.peterson

Dans mon cas, c'est parce que j'ai accidentellement supprimé (non supprimé) les fichiers stdafx.h et targetver.h de la section Header Files .

Ajoutez ces fichiers dans Header Files et le problème est résolu.

J'ai eu ces:

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

J'ai juste besoin de commenter cela (en ajoutant le // au début) et c'est bien.

0
Hendy Irawan

J'ai eu le problème avant, mais c'était résolu. Le problème principal était que j'épelle par erreur la fonction int main (). Au lieu d'écrire int main (), j'ai écrit int mian () .... Salut!

0
Serign Modou Bah

 Screen snapshot Visual Studio 2015

Configurez le système sur console en suivant les suggestions précédentes. Seulement, devait également changer le jeu de caractères en Unicode, voir l'instantané de Visual Studio 2015 ci-dessus.

0
LastBlow