erreur LNK2005: _DllMain @ 12 déjà défini dans MSVCRT.lib
Je reçois cette erreur de l'éditeur de liens.
mfcs80.lib (dllmodul.obj): erreur LNK2005: _DllMain @ 12 déjà définie dans MSVCRT.lib (dllmain.obj)
S'il vous plaît dites-moi la bonne façon d'éliminer ce bug. J'ai lu la solution sur le site de support de Microsoft à propos de ce bogue mais cela ne m'a pas beaucoup aidé.
J'utilise VS 2005 avec Platform SDK
Si vous lisez attentivement l'erreur de l'éditeur de liens et appliquez certaines connaissances, vous pouvez y arriver vous-même:
L'éditeur de liens relie un certain nombre d'objets et de bibliothèques compilés pour obtenir un binaire.
Chaque objet/bibliothèque décrit
- quels symboles il s'attend à être présent dans d'autres objets
- quels symboles il définit
Si deux objets définissent le même symbole, vous obtenez exactement cette erreur de l'éditeur de liens. Dans votre cas, mfcs80.lib et MSVCRT.lib définissent le symbole _DllMain @ 12.
Se débarrasser de l'erreur:
- savoir laquelle des deux bibliothèques dont vous avez réellement besoin
- savoir comment dire à l'éditeur de liens de ne pas utiliser l'autre (en utilisant, par exemple, le conseil de James Hopkin )
J'ai eu le même message d'erreur, mais aucune des réponses ici ne l'a résolu pour moi. Donc, si vous rencontrez ce problème lors de la création d'un projet DLL qui utilise MFC, vous pouvez le résoudre en saisissant la ligne suivante:
extern "C" { int _afxForceUSRDLL; }
dans le fichier cpp où DllMain est défini. Ensuite, votre propre implémentation DllMain est utilisée, plutôt que celle de dllmain.obj.
Lorsque nous essayons d'utiliser la bibliothèque MFC, nous inclurons certainement afx.h directement ou indirectement, MFC (afx.h) demande à l'éditeur de liens de trouver le symbole de __afxForceUSRDLL et mettez cet objet qui contient __afxForceUSRDLL dans le programme, donc l'éditeur de liens effectue une recherche et place dllmodule.obj dans notre programme, car __afxForceUSRDLL est défini dans dllmodule.cpp.
C’est le scénario habituel. Lorsque nous voulons utiliser notre propre DllMain dans un fichier mfc dll project, l'éditeur de liens se plaint qu'il y a deux DllMain, un dans notre code, un dans Dllmodule.obj.
Nous devons donc dire à l'éditeur de liens d'ajouter notre dllmain.obj pour __afxForceUSRDLL. Nous devons donc définir __afxForceUSRDLL dans notre propre fichier cpp, où notre propre fichier DllMain est défini, l’éditeur de liens ignorera alors mfc’s dllmodule.obj et ne voyez qu’un seul DllMain et ne vous plaint jamais.
Si vous définissez votre propre DllMain, vous devez définir dans les paramètres de votre projet "Utilisation de MFC" dans "Propriétés de la configuration/Général" sur "Utiliser les bibliothèques Windows standard".
Vous devriez faire une reconstruction propre après l'avoir changée.
Dans mon projet, j'ai pu résoudre ce problème en ajoutant les dépendances supplémentaires mfcs80.lib et msvcrt.lib dans les paramètres du projet. Les 'dépendances supplémentaires' se trouvent sous Linker -> Input.
Dans la configuration de débogage, cela devrait être respectivement mfcs80d.lib et msvcrtd.lib.
En passant, je travaille avec Visual Studio 2010, de sorte que dans mon cas, la bibliothèque MFC s'appelle mfc100.lib.
Je ne sais pas pourquoi cela a fonctionné. Il n'est pas nécessaire d'ajouter ces fichiers lib en tant que dépendances supplémentaires, car j'ai déjà défini "Utilisation de MFC" sur "Utiliser MFC dans une dll partagée". J'imagine qu'en spécifiant ces bibliothèques comme dépendances supplémentaires, elles sont liées dans un ordre différent.
Cette solution est plus ou moins la même que celle suggérée sur le site de Microsoft: http://support.Microsoft.com/kb/148652 , sauf que je n'ai pas eu besoin de taper quoi que ce soit dans 'Ignorer des bibliothèques spécifiques ' boîte.
Pour moi, la cause directe était bien une référence de symbole _afxForceUSRDLL manquante, mais la cause indirecte était une définition de macro _USRDLL manquante. Il est défini par défaut par l’assistant VC, mais il arrive que les développeurs l’effacent par erreur . Le voici en plusieurs mots .
ID de la base de connaissances MSDN Q148652.
http://support.Microsoft.com/kb/148652
Cause: Visual C++ compile les fichiers source dans l'ordre alphabétique et les transmet à l'éditeur de liens dans l'ordre alphabétique . Si l'éditeur de liens traite d'abord DLLDATAX.OBJ, le code source fait référence à DllMain, qu'il charge. à partir de MSVCRTD.LIB (dllmain.obj) . Le lieur traite ensuite un fichier objet compilé à partir d'un fichier C++ contenant #include "stdafx.h", qui fait référence au symbole __ afxForceUSRDLL, qu'il charge depuis MFC42D .LIB (dllmodul.obj). Ce module objet contient également une implémentation pour DllMain, causant le conflit.
Pour tous ceux qui rencontrent cette erreur dans les projets ATL (principalement en essayant d'ajouter le support MFC), voici la solution que j'ai trouvée après des jours de frustration!
Tout d’abord, ce lien m’a été plus utile que tous les autres. Cela m'a orienté dans la bonne direction. Le problème se produit si, pour une raison quelconque, les "fichiers générés" (contenant le code proxy et le code stub, ont été supprimés et lus au projet. Cela oblige Visual Studio à les ajouter dans le mauvais ordre!
En général, vous rencontrez d’abord l’erreur "ATL nécessite la compilation C++", mais vous avez peut-être résolu le problème en désactivant le paramètre Yc/Yu (en-têtes précompilés) pour ce fichier.
Ce que vous devez faire ensuite est de décharger votre projet et de le modifier. Recherchez les groupes d'articles qui définissent l'ordre de construction et d'inclusion (ClCompile et ClInclude). Vérifiez leur ordre et leurs paramètres.
Les compilations doivent apparaître dans cet ordre:
dllmain.cpp(avecCompileAsManageddéfini surfalseetPrecompiledHeaderlaissé vide).- Source de la bibliothèque (
MyLib.cpp, contenantDllCanUnloadNowet ainsi de suite) - Code proxy/stub (
MyLib_i.c; avec les mêmes paramètres quedllmain.cpp) stdafx.cpp(avecPrecompiledHeaderdéfini surCreate)- Tous les autres fichiers sources de la bibliothèque (le contenu actuel de votre bibliothèque)
xdlldata.c(avec les mêmes paramètres quedllmain.cpp)
Le includes devrait alors être commandé comme ceci:
dllmain.hMyLib_i.hResource.hstdafx.htargetver.h- ... (en-têtes de bibliothèque actuels)
xdlldata.h
La correction de l'ordre de génération a corrigé mon projet et j'ai pu créer une nouvelle version propre.
J'ai un problème très similaire. [mfcs110d.lib (dllmodul.obj): erreur LNK2005: _DllMain @ 12 déjà défini dans MSVCRTD.lib (dllmain.obj)] et la solution était ajoutez mfcs110d.lib à des dépendances supplémentaires
Nel mio caso a résolu un problème de pré-traitement. Per qualche motivo _USRDLL è stato definito, quando non avrebbe dovuto essere.
Per Verificare questo, vai al menuProjectselezionareProject Properties, quindi seleziona lo snippetConfiguration Properties->Preprocessor.
Le répertoire du préprocesseur saranno trovate lì.
Je me suis personnellement débarrassé de cette erreur de cette façon: projet cliqué avec le bouton droit dans Solution Explorer, sélectionné Properties dans le menu contextuel, cliqué sur l'onglet Linker et ajout de mfcs71ud.lib dans Additional Dependencies. Si vous utilisez Visual Studio 2005, il devrait être "80" au lieu de "71" et ainsi de suite.
Juste #undef le _USRDLL avant d'inclure afx.h, voire mieux, éditez la configuration de votre projet et supprimez la macro.
Voici la configuration habituelle pour une DLL d'extension MFC: Créer les paramètres pour un MFC DLL
Il existe un thème commun à certaines des réponses ici.
Avishek Bose: -
Déclarez les fichiers mfc80ud.lib et mfcs80ud.lib dans le champ Dépendances supplémentaires de la fenêtre Propriétés du projet -> Éditeur de liens -> Entrée de Visual Studio pour résoudre le problème.
vmb100: -
Je travaille avec Visual Studio 2010, donc dans mon cas, la librairie MFC s'appelle mfc100.lib.
joseAndresGomezTovar: -
J'ai un problème très similaire. [mfcs110d.lib (dllmodul.obj): erreur LNK2005: _DllMain @ 12 déjà défini dans MSVCRTD.lib (dllmain.obj)] et la solution a été ajoutée à mfcs110d.lib à des dépendances supplémentaires
Le cas général semble donc être de trouver d'abord le nom de la bibliothèque à ajouter ...
et ensuite l'ajouter ....
Notez qu'il semble y avoir des solutions conditions préalables et/ou alternatives .
J'ai trouvé la solution ici Ordre de liaison de la bibliothèque Visual Studio 2010
c'est:/FORCE: MULTIPLE dans les options de l'éditeur de liens
Je devais mélanger ATL et MFC ensemble, pour utiliser [Module (name = "mymodule")]; construction dans l'application MFC avec le mot clé "__hook"
Déclarez les mfc80ud.lib et mfcs80ud.lib dans le champ Additional Dependancies du Project Properties -> Linker Tab -> Input of Visual Studio pour résoudre le problème.
J'ai trouvé ceci qui m'a aidé: http://support.Microsoft.com/kb/148652
Fondamentalement, l'ordre de l'éditeur de liens était incorrect. les bibliothèques CRT devenaient liées avant les bibliothèques MFC. Il s'est avéré que les bibliothèques MFC devaient être liées en premier, puis que les bibliothèques CRT pouvaient être liées.
Yucko Microsoft !!
Assurez-vous d'inclure "Stdafx.h" en haut de chaque fichier .cpp. J'obtenais exactement la même erreur et j'avais un seul fichier .cpp qui n'incluait pas cet en-tête du tout. L'ajout de #include a résolu le problème.