Bonjoru tous !
 
Un petit problème c'est déclaré sur mon appli, et j'ai rien trouvé dessus sur le net et autre.
 
J'ai pondu une librairie ( un dll kwoa) utilisant les MFC.  
 
Le problème est que la dll obtenue dépend des dlls mfc71d.dll et msvcr71d.dll.
 
Ce sont les dlls de debug de crosoft pour les mfc a priori, et elles sont po mal lourdes. j'aimerai bien ne dépendre que de mfc71.dll et pas mfc71d.dll, qui est son pendant pour le debug.
 
j'ai essayé, en lsiant sur la MSN, de lier les librairies statiquemment. A priori, mon soft aime PAS DU TOUT car il ne compile plus du tout
 
Quellqu'un sait quelle option changer lors de la compil sous VS .net en C++ pour avoir une dll compilée  dépendant de mfc71.dll et pas  MFC71D.DLL ?  
 
Si c'est une question bateau, désolé, mais j'ai du apprendre ce soft pour ce prog alors je rame un peu
 
merci

Tu dois compiler ton projet en mode Release et pas en mode Debug

 
Ok, ben je vais en suer, car ca compile qu'en mode debug
 
Enfin merci je vais me pencher sur le sujet

atlsd.lib(Externs.obj) : error LNK2005: "char const * const g_pszUpdateEventName" (?g_pszUpdateEventName@@3PBDB) already defined in atls.lib(Externs.obj)
 
Comment que ca se fait une erreur pareille ?

ca j'ai réglé l'sooci, maintenant j'ai ca quand je demmande "MFC in a shared dll"
 
error LNK2005: __lseek already defined in libcmt.lib(lseek.obj)
 
Pourtant, je lui ai demandé d'ignorer la librairie spécifique libcmt.lib dans le projet, mais y a pas

chpeux faire un up ?
 
et je détaille un peu plus.
 
maintenant, mon but est de compiler la DLL en utilsant les MFC en DLL, et le Multi-threaded ( /Md ).
 
Bref, vla mon souci :
 
Quand je compile le prog en lui demandant d'exclure libcmt.lib ( /NODEFAULTLIBRARY:libcmt.lib ), il me sort des erreurs comme :
 

 
Si j'enleve l'option d'ignorance de libcmt.lib :
 

 
Quand je mets libcmt en "additional dependencies" et dans le "ignore specific library", j'ai :
 

 
Enfin, si je mets  libcmt.lib en additional depedencies, dans inore specific libraries et que je lui demande un lien statique vers les MFC, la compilation marche, mais ce n'est pas  ce que je veux.
 
Une idée pour que ca passe en "MFC in shared DLL"?

je m'arrache les cheveux la

Tu dois linker ta dll avec une lib utilisant les mfcs en statique non??

le problème est que compiler en statique fait merder mon prog alors qu'en dynamique et end ebug ca marche...
 
Donc l'option statique n'en est pas une

Ce que je soupconne, c que ton DLL, que tu cherches à compiler en MFC shared dll, utilise (et donc fait un link avec) une lib (peut-être la déclaration d'un autre dll) à toi ou à une partie externe qui aie comme réglage MFC static.
Est-ce le cas??
Désolé c tt ce que je peux te dire, si c pas le cas je ne comprends pas non plus.

Merci e ton aide, mais je ne linke qu'avec des librairies classiques et des progs en assembleur... donc je pense pas que cela soit le problème.
 
D'ailleurs le link est le même qu'en mode debug, et en mode debug en shared dll ca compile parfaitement
 
D'ou dilemne

De toute façon, si tu ne parviens à compiler qu'en mode debug, c'est que t'as une merde dans ton source, faut pas chercher !
Un truc du style écriture là ou il ne faut pas, etc...

Ben le souci c'est que la compilation en mode statique et release passe sans souci ! mais l'image ne marche pas.
 
En mode debug et shared DLL aussi ca marche nickel chrome, et image fonctionelle.
 
Debug + statique ca marche aussi, mais image non fonctionelle.
 
Par contre en release + shared DLL j'y arrive pas

eup

Bizarre que ta dll ne marche pas en mode statique... Je vois pas trop d'où pourrait venir cette différence.
 
Sinon, la lib "libcmt.lib", c'est la bibliothèque C standard multithread (tu l'avais sûrement défini) et le message d'erreur qu'il te met indique que tu cherches à mettre deux fois une fonction "__close" dans ton programme. Une première fois en linkant avec "libcmt.lib" et la deuxième autre part dans ton programme (par exemple lors d'un link avec une autre bibliothèque C). J'aurais tendance à croire que la deuxième fois, c'est dans la version Debug de la bibliothèque C multithread qu'il va chercher la fonction. En effet, ça expliquerait pourquoi en mode Debug ça marche bien (il utilise la même lib).

Merci pour ton explication
 
Donc selon toi, comment je peux identifier exactement ou est le problème et comment le  regler ?
 
Car a part un lien avec libcmt.lib , je fais rien d'extraordinaire... Et je pense pas importer d'autre libs spéciales...

 
Très bonne question... Je te remercie de l'avoir posée.
 
A vrai dire, si tu n'utilise pas d'autre libs externes, je ne comprend vraiment pas. Car je ne vois pas pourquoi un seul programme lierait avec deux versions différentes d'une même lib
.
En y réflechissant, je ne suis même plus sûr de mon explication. En effet, il m'est déjà arrivé de lier un programme (sous Visual C++ 6 et 7) avec la lib C Debug alors qu'il utilisait une lib elle même liée avec la lib C Release et cela ne posait pas de problèmes (juste un Warning qu'il est possible d'ignorer).
 
J'aurais tendance à croire que ton problème vient de l'utilisation des MFC. En effet, je ne vois que ça qui pourrait avoir besoin de linker sans que tu le saches. Je n'ai jamais fait de DLL en utilisant les MFC donc je peut pas plus t'aider.
 
Tu peut peut être également utiliser depends sur le programme créé en mode Debug afin de voir de quelles libs sont utilisées et également repérer quelles libs exportent la fonction "__close".
 
J'ai relu un peu le sujet et je persiste à croire que c'est un problème entre Debug et Release. En effet, dans "atlsd.lib ... already defined in atls.lib(Externs.obj)", on voit qu'il lie à la fois avec atls.lib (version Release) et atlsd.lib.
 
Tu peut peut être essayer de recréer un projet vide (avec les options par défaut) et faire un copier/coller de ton code. Pas très propre, mais il est parfois dur de se souvenir des paramètres qu'on a modifié.
 
Tu peut aussi aller voir cette page "Surviving the release build qui contiendra peut être ta réponse.
 
J'aurais également tendance à me poser la question : "Pourquoi ma DLL ne marche pas si je compile en static ?". C'est peut être également la cause de tes autres problèmes.

 
Ok, je testerai des que je serai rentré chez moi Merci