Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2031 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  [C++ | VS .NET] MFC, ca va pas en "MFC in shared DLL" mais static oui

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[C++ | VS .NET] MFC, ca va pas en "MFC in shared DLL" mais static oui

n°431788
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 12:23:51  profilanswer
 

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 :sweat:
 
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 :D
 
merci :jap:


Message édité par Tetedeiench le 18-06-2003 à 17:20:24
mood
Publicité
Posté le 18-06-2003 à 12:23:51  profilanswer
 

n°431800
Harkonnen
Modérateur
Un modo pour les bannir tous
Posté le 18-06-2003 à 12:28:00  profilanswer
 

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


---------------
J'ai un string dans l'array (Paris Hilton)
n°431815
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 12:38:41  profilanswer
 

Harkonnen a écrit :

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 :cry:
 
Enfin merci je vais me pencher sur le sujet :jap:

n°431847
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 13:13:23  profilanswer
 

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 ? :/

n°431864
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 13:38:53  profilanswer
 

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 :/


Message édité par Tetedeiench le 18-06-2003 à 17:13:21
n°432111
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 17:01:11  profilanswer
 

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 :
 

Citation :

error LNK2001: unresolved external symbol ___argv


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

Citation :

error LNK2005: __close already defined in LIBCMT.lib(close.obj)


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

Citation :

Prime95 error LNK2005: __close already defined in libcmt.lib(close.obj)


 
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"?


Message édité par Tetedeiench le 18-06-2003 à 17:19:29
n°432189
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 17:39:15  profilanswer
 

je m'arrache les cheveux la :cry:

n°432210
H4dd3R
Q2
Posté le 18-06-2003 à 17:56:36  profilanswer
 

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


---------------
Athlon64 s754 10*200MHz - R9800Pro - 512MB DDR200MHz - ZX6RR - Q2[SupOp] - Tutorial Video: multilangues, multisstitres
n°432242
Tetedeienc​h
Head Of God
Posté le 18-06-2003 à 18:27:52  profilanswer
 

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 :sweat:

n°432673
H4dd3R
Q2
Posté le 19-06-2003 à 09:39:20  profilanswer
 

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.


---------------
Athlon64 s754 10*200MHz - R9800Pro - 512MB DDR200MHz - ZX6RR - Q2[SupOp] - Tutorial Video: multilangues, multisstitres
mood
Publicité
Posté le 19-06-2003 à 09:39:20  profilanswer
 

n°432719
Tetedeienc​h
Head Of God
Posté le 19-06-2003 à 10:30:59  profilanswer
 

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 :/

n°432721
Harkonnen
Modérateur
Un modo pour les bannir tous
Posté le 19-06-2003 à 10:33:43  profilanswer
 

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...


---------------
J'ai un string dans l'array (Paris Hilton)
n°432746
Tetedeienc​h
Head Of God
Posté le 19-06-2003 à 11:00:26  profilanswer
 

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 :'(


Message édité par Tetedeiench le 19-06-2003 à 11:01:06
n°433422
Tetedeienc​h
Head Of God
Posté le 19-06-2003 à 21:06:40  profilanswer
 

eup :cry:

n°433466
gatorette
Posté le 19-06-2003 à 21:59:46  profilanswer
 

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).


---------------
each day I don't die is cheating
n°434033
Tetedeienc​h
Head Of God
Posté le 20-06-2003 à 10:11:16  profilanswer
 

Merci pour ton explication :jap:
 
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...

n°434169
gatorette
Posté le 20-06-2003 à 11:45:41  profilanswer
 

tetedeiench a écrit :

Donc selon toi, comment je peux identifier exactement ou est le problème et comment le  regler ?


 
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.


---------------
each day I don't die is cheating
n°434228
Tetedeienc​h
Head Of God
Posté le 20-06-2003 à 13:43:36  profilanswer
 

gatorette a écrit :


 
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 :jap:


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  [C++ | VS .NET] MFC, ca va pas en "MFC in shared DLL" mais static oui

 

Sujets relatifs
Gros problème : DLL manquante..[MFC] Icones d'une ListCtrl > fond noir > transparent
[MFC] CString en argument d'une méthode > LPCTSTR[MFC] CTreeCtrl > NMTREEVIEW avec OnSelChange...
[C/C++] - Librairies DLL et ActiveX pour l'utilisation du RS232[MC++] Comment utiliser une dll .NET en MC++ ?
[Visual C++] Definir le texte d'un "static text" control.NET : Dataset et persistance
Chargement de fonction d'une librairie DLL[MFC] Tri special
Plus de sujets relatifs à : [C++ | VS .NET] MFC, ca va pas en "MFC in shared DLL" mais static oui


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR