Symbole externes non résolu pour wargv et argc

Discussion générale Symbole externes non résolu pour wargv et argc

  • mardi 10 avril 2012 07:40
     
     

    J'ai créé une application MDI dans laquelle j’introduis CUDA, et à l'édition de lien les deux messages apparaissent:

    1>uafxcwd.lib(appcore.obj) : error LNK2001: symbole externe non résolu ___wargv
    1>uafxcwd.lib(appcore.obj) : error LNK2001: symbole externe non résolu ___argc

    Il n'y a pas de wmain et donc d'arguments wargv et argc car l'application se lance en construisant une instance de l'application

    CWinAppEx.

    Pourquoi cette bibliothèque a besoin de ces deux déclarations, et comment la remplacer ?

    Si je l'enlève, il me manque ses fonctionnalités.

    Merci

    English:

    I Have create a MDI application wherein I introduce CUDA, and when it's linging the following messages occures:

    1>uafxcwd.lib(appcore.obj) : error LNK2001: symbole externe non résolu ___wargv
    1>uafxcwd.lib(appcore.obj) : error LNK2001: symbole externe non résolu ___argc

    The i not wmain function because the MDI application use the constructor of the CWinAppEx object and therefore the wargv and argc are not reported.

    Why this librarie needs the wargw and argc and how to create them ?

    I can't put out this library.

    Thanks

Toutes les réponses

  • mardi 10 avril 2012 13:14
    Auteur de réponse
     
     

    Les symboles __argc et __wargv sont définis dans stdlib.h, et dans le runtime C classique. Ils sont requis par uafxcwd.lib, une librairie MFC utilisée lorsque l'on compile un module (LIB/DLL/EXE) avec la version statique de la bibliothèque MFC.

    Je me demande si certains de vos modules ne sont pas compilés avec /MT (link statique avec la bibliothèque MFC) et d'autres avec /MD (link dynamique avec la bibliothèque MFC). Vérifiez que vous utilisez bien les MFC de la même manière dans tous vos modules, soit dynamiquement, soit statiquement.

    Voir les options dans les propriétés du projet, onglet "Général", "Utilisation des MFC" : statique ou dynamique. De ce choix dépend le choix de l'option /MD ou /MT dans l'onglet "C/C++", "Génération de code".

  • mercredi 11 avril 2012 13:48
     
     

    Bonjour,

    J'ai essayé, mais le projet est dans l'option:

    Général>Utilisation des MFC>Utiliser les MFC dans une bibliothèque statique

    Pour la version Debug:

    C/C++>Génération de code>Bibliothèques Runtime /MTd

    Pour la version release

    C/C++>Génération de code>Bibliothèques Runtime /MT

    Donc, ce n'est pas ce problème, car mon projet fonctionnait avant l'introduction des fonctionnalités CUDA.

    C'est un projet MDI, dans lequel j'introduit CUDA avec le compilateur NVCC...

    Je pense que le pb vient de là:

    Pour un pb d'ordre des librairies, (double déclaration) j'ai du rajouter dans les propriétés du projet:

    Editeur de lien>entrée>Dépendances supplémentaires

    cudart.lib
    uafxcwd.lib
    msvcrtd.lib

    Et

    Bibliothèques par défaut spécifiques ignorées (Debug)

    uafxcwd.lib
    Libcmtd.lib
    msvcrtd.lib

    Bibliothèques par defaut spécifiques ignorées (Release)

    uafxcw.lib
    Libcmt.lib
    msvcrt.lib

    Voila, Voila

    Une idée ?

    Merci


    • Modifié bmoraut mercredi 11 avril 2012 13:48
    •  
  • jeudi 12 avril 2012 00:10
    Auteur de réponse
     
     

    Bibliothèques par défaut spécifiques ignorées (Debug)

    uafxcwd.lib
    Libcmtd.lib
    msvcrtd.lib

    Les MFC ont besoin de libcmt.lib, uafxcwd.lib et msvcrt.lib. Je ne pense pas qu'il soit possible de linker une appli MFC sans ces librairies. C'est normal d'avoir des erreurs au link en supprimant ces librairies. D'ailleurs, il ne doit pas y avoir que deux erreurs ?

    Pourquoi supprimer ces librairies ?

  • jeudi 12 avril 2012 14:56
     
     

    Les librairie incriminées sont enlevées dans les commande "Bibliothèques supé..ignorées" et

    elles sont remises dans la commande

    Editeur de lien>entrée>Dépendances supplémentaires

    cudart.lib
    uafxcwd.lib
    msvcrtd.lib

    pour être dans le bon ordre (autres erreurs de liens résolu dans un forum Microsoft.

    Et il reste bien deux erreurs!

    Juste les deux déclarations argc et warv, dont on n'a plus besoin dans Visual 2010, avec l'objet Application.

    Ces deux arguments, sont les ligne de commandes passées au programme dans les anciennes structures 2005, Visual 6 et Visual 2008.

    J'ai bien précisé qu'il s’agit d'un application MDI.

    Je ne vois pas pourquoi le bibliothèque uafxcw et uafxcwd pour le mode débug, ont besoin de ces déclarations.

    Merci de répondre si vous connaissez Visual 2010 en MDI.

  • jeudi 12 avril 2012 18:19
    Auteur de réponse
     
     
    Ces deux arguments, sont les ligne de commandes passées au programme dans les anciennes structures 2005, Visual 6 et Visual 2008.

    Non, ils sont toujours d'actualité avec VS2010.

    Je ne vois pas pourquoi le bibliothèque uafxcw et uafxcwd pour le mode débug, ont besoin de ces déclarations.

    Parce que ces déclarations sont utilisées par uafxcw.lib dans le fichier <programfiles>\Microsoft Visual Studio 10.0\VC\atlmfc\src\mfc\appcore.cpp

    Encore une fois, supprimer libcmt ne peut que provoquer des problèmes.

  • vendredi 13 avril 2012 09:39
     
     

    SI je la remets j'ai plus d'erreurs:

    1>------ Début de la génération : Projet : Nadia, Configuration : Debug Win32 ------
    1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: _exit déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: __exit déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: __cexit déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: __amsg_exit déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: __initterm_e déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(crt0init.obj) : error LNK2005: ___xi_a déjà défini(e) dans msvcrtd.lib(cinitexe.obj)
    1>LIBCMTD.lib(crt0init.obj) : error LNK2005: ___xi_z déjà défini(e) dans msvcrtd.lib(cinitexe.obj)
    1>LIBCMTD.lib(crt0init.obj) : error LNK2005: ___xc_a déjà défini(e) dans msvcrtd.lib(cinitexe.obj)
    1>LIBCMTD.lib(crt0init.obj) : error LNK2005: ___xc_z déjà défini(e) dans msvcrtd.lib(cinitexe.obj)
    1>LIBCMTD.lib(hooks.obj) : error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(invarg.obj) : error LNK2005: __invoke_watson déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(errmode.obj) : error LNK2005: ___set_app_type déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __malloc_dbg déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __recalloc déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __expand déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __free_dbg déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __msize déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetBreakAlloc déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetAllocHook déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtCheckMemory déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetDbgFlag déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtDoForAllClientObjects déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtIsMemoryBlock déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtReportBlockType déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetDumpClient déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtMemCheckpoint déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtMemDifference déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtMemDumpAllObjectsSince déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtDumpMemoryLeaks déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtMemDumpStatistics déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetCheckCount déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(mlock.obj) : error LNK2005: __lock déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(mlock.obj) : error LNK2005: __unlock déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(winxfltr.obj) : error LNK2005: __XcptFilter déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dosmap.obj) : error LNK2005: __errno déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dosmap.obj) : error LNK2005: ___doserrno déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(dbghook.obj) : error LNK2005: __crt_debugger_hook déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswalpha déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswdigit déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswspace déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswalnum déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswprint déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LIBCMTD.lib(setlocal.obj) : error LNK2005: __configthreadlocale déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)
    1>LINK : warning LNK4098: conflit entre la bibliothèque par défaut 'LIBCMTD' et les autres bibliothèques ; utilisez /NODEFAULTLIB:library
    1>LIBCMTD.lib(crt0.obj) : error LNK2019: symbole externe non résolu _main référencé dans la fonction ___tmainCRTStartup
    1>D:\Mes docs\F - DVD 6 - Prog et 3D\VII - Sources C++\Nadia\Nadia V 1-186\Debug\Nadia.exe : fatal error LNK1120: 1 externes non résolus

    Désolé, mais je ne vous comprends pas, un article explique que libcmt.lib (et libcmtd.lib) avec (msvcrtd.lib) ne sont pas dans le bon ordre dans Visual 2010, donc dans cet article il fon supprimer, puis remttre dans le bon ordre pour le linkage ces deux bibliothèques

    Si je la remets, dans un sens ou l'autre (avant ou après msvcrtd.lib), avec Bib suplémentaire rajoutée, j'ai des erreurs entre :

    1>  Génération de code en cours...
    1>msvcrtd.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) déjà défini(e) dans libcmtd.lib(typinfo.obj)
    1>msvcrtd.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) déjà défini(e) dans libcmtd.lib(typinfo.obj)
    1>D:\Mes docs\F - DVD 6 - Prog et 3D\VII - Sources C++\Nadia\Nadia V 1-186\Debug\Nadia.exe : fatal error LNK1169: un ou plusieurs symboles définis à différentes reprises ont été rencontrés

    Donc, ce que j'ai compris, c'est que cette bibliothèque, DANS UNE APPLICATION MDI est remplacée par msvcrtd.lib.

    Et il compile, si je l'enlève, avec seulement 2 erreurs:

    1>------ Début de la génération : Projet : Nadia, Configuration : Debug Win32 ------
    1>uafxcwd.lib(appcore.obj) : error LNK2001: symbole externe non résolu ___wargv
    1>uafxcwd.lib(appcore.obj) : error LNK2001: symbole externe non résolu ___argc
    1>D:\Mes docs\F - DVD 6 - Prog et 3D\VII - Sources C++\Nadia\Nadia V 1-186\Debug\Nadia.exe : fatal error LNK1120: 2 externes non résolus

    Ce qui est bien un pb pour uniquement les déclarations de wargv et agrc, qui je pense, sont utilsés par cudart.lib.

    Ma question est: comment les déclarer pour uafxcwd.lib?

    Merci

  • vendredi 13 avril 2012 15:57
    Auteur de réponse
     
     

    Désolé, mais je ne vous comprends pas, un article explique que libcmt.lib (et libcmtd.lib)
    avec (msvcrtd.lib) ne sont pas dans le bon ordre dans Visual 2010, donc dans cet article
    > il fon supprimer, puis remttre dans le bon ordre pour le linkage ces deux bibliothèques

    Il ne faut pas croire tout ce que l'on raconte ici ou là !

    Il n'y a pas besoin de changer l'ordre des librairies pour une appli MFC (MDI ou pas).

    Après, je ne sais pas s'il faut faire des manipulations spéciales pour Cuda. Mais visiblement, "changer l'ordre des librairies" n'est pas une bonne solution puisque cela provoque des erreurs au link.

  • mercredi 18 avril 2012 13:23
    Modérateur
     
     

    1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: _exit déjà défini(e) dans msvcrtd.lib(MSVCR100D.dll)

    C'est pas compliqué, vous ne pouvez-pas liker un même module avec les librairies "LIBCMTD.lib" et "msvcrtd.lib" en même temps.

    Il reste plus qu'à remonté la cause de l'ajout des ces 2 libs incompatibles.


    Paul Bacelar, Ex - MVP VC++

  • dimanche 22 avril 2012 06:19
     
     

    Bonjour,

    J'ai réussi à résoudre mon pb par hasard en tombant sur l'article:

    Avertissement des outils Éditeur de liens LNK4098

    Article, qui fait ignorer les librairies :

    libc;libcmt;msvcrt;msvcrtd

    En en changeant l'ordre des librairies uafxcw et libmsvcrt: (avec un d pour mode debug)

    Ignorer uafxcw et libmsvcrt:

    Rajouter dans l'ordre uafxcw et libmsvcrt:

    En fait, il semble que l'organisation des librairie sont anarchiques dans les exemples CUDA.

    Quand vous dites "Il reste plus qu'à remonté la cause de l'ajout des ces 2 libs incompatibles."

    y a-t-il un outils qui permet de connaitre le graphe des dépendances des librairies utilisées dans les sources avec dans Visual ?

    Merci

  • mercredi 2 mai 2012 10:46
    Modérateur
     
     

    Si mes souvenir sont bon l'ordre de déclaration des libs n'a aucune importance avec le linker de VS.

    La manière de travailler du linker de VS est bien différentes de celui de gcc. Pour ce type de linker (gcc), oui l'ordre est important, mais pas sous VS.

    Sous VS, le linker prend toutes les libs et gueule quand il voit des doublons, d'où le message d'erreur "error LNK2005".

    Sous VS, je ne vois que 3 manières de spécifier les libs :

    - Dans un projet à la MSBUILD ou en ligne de commande, les donner dans les paramètres de la ligne de commande

    - Dans un projet dans l'IDE VS, dans les paramètres du projet

    - Dans les sources du projet via un "#pragma comment(lib,....".

    Donc mes outils dans ce cas, c'est vérification de la ligne de commande, des paramètres du projet, et une recherche dans les sources d'un "#pragma comment".

    Généralement, ce genre de problème vient d'une erreur dans la configuration du projet car on n'a pas suivi la documentation fournie.

    Dans les projets fournissant une intégration dans VS, ce genre de détaille sur le type de C-Runtime à utiliser etc., est explicitement fourni.

    Je pense donc que vos déboires viennent du faite que vous n'avez pas lu assez attentivement la documentation. Ou la documentation a de très grosses lacunes.

    Le but n'est pas de trouvez une combinaison qui "marche" mais de savoir pourquoi vous êtes tombé sur ce problème. Le problème étant un mélange de librairies incompatibles. Je rappel que ce type d'incompatibilité est très fréquente et que celles impliquant les C-Runtime doivent être documentées.

    Relisez la documentation du projet et vérifiez que vous n'avez pas oublié un détail sur la configuration du projet.


    Paul Bacelar, Ex - MVP VC++