Tu peux regarder ce fichier de configuration de la biblioth�que Ogre par exemple, et regarder comment ils d�clarent la macro _OgreExport selon les diff�rents syst�mes :
http://www.ogre3d.org/docs/api/html/...8h-source.html
Version imprimable
Tu peux regarder ce fichier de configuration de la biblioth�que Ogre par exemple, et regarder comment ils d�clarent la macro _OgreExport selon les diff�rents syst�mes :
http://www.ogre3d.org/docs/api/html/...8h-source.html
Ca va aider, mais on y voit que GCC (version ant�rieure � 4) n'accepte pas de syntaxe similaire � Windows. Donc je vois pas comment on y fait des librairies partag�es. Mais l'important pour moi c'est Windows.Citation:
Tu peux regarder ce fichier de configuration de la biblioth�que Ogre par exemple, et regarder comment ils d�clarent la macro _OgreExport selon les diff�rents syst�mes
J'ai cr�� ma petite DLL, mais j'ai d�j� un 1er probl�me: j'arrive pas � la lier au programme.
J'aimerais �viter l'�dition de lien implicite (GetProcAdress) car j'ai vu dans la doc de Visual, qu'il y a la possibilit� plus facile d'une �dition de lien implicite.
C'est bien joli tout �a, mais je vois pas de fichier .LIB (import library) cr�� en m�me temps que la DLL, comme le sugg�re pourtant la doc de Visual.Citation:
To implicitly link to a DLL, executables must obtain the following from the provider of the DLL:
-A header file (.H file) containing the declarations of the exported functions and/or C++ classes.
-An import library (.LIB files) to link with. (The linker creates the import library when the DLL is built.)
-The actual DLL (.DLL file).
Executables using the DLL must include the header file containing the exported functions (or C++ classes) in each source file that contains calls to the exported functions. From a coding perspective, the function calls to the exported functions are just like any other function call.
To build the calling executable file, you must link with the import library. If you are using an external makefile, specify the file name of the import library where you list other object (.OBJ) files or libraries that you are linking with.
Des id�es?
En fait, pour GCC, les fonctions sont export�es par d�faut, il n'y a pas d'import/export � faire.
- GetProcAddress(), c'est EXplicite.
- Quelles sont tes options de compilation? regarde si tu n'as pas oubli� d'en activer une... (genre "import library" � activer ou "doesn't produce .lib" � supprimer)
Edit: Sous visual 2005 pro, j'ai l'option Project Properties->Configuration Properties->Linker->Advanced->Import Library
Ca c'est de la r�ponse rapide. :D Merci
Je comprends pas, �a marche maintenant, le linker me cr�e bien un '.dll' ET un '.lib'.
J'avais juste v�rifi� dans le projet si l'option 'Import Library' �tait correcte, et elle l'�tait: "$(OutDir)/$(TargetName).lib". Je touche du bois...
Ca marche nickel avec une DLL: plus de d�pendance, et pas de changement majeur dans le code source gr�ce � l'�dition de lien implicite.
J'ai rajout� ceci dans l'ent�te de configuration
Je coupe les cheveux en 4, mais j'ai encore 2 petites questions:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
- Y a t-il un moyen de reconna�tre automatiquement (avec un #ifdef ?) , si le projet compile une DLL ou une LIB? Ca m'�viterait d'avoir � modifier manuellement l'ent�te de configuration � chaque changement de projet.
- Il faut que l'ex�cutable trouve la DLL. A ma connaissance, il faut donc que la DLL soit dans le m�me r�pertoire que l'executable ou bien dans l'un des r�pertoires du PATH. Mais ni l'un ni l'autre n'est pratique parce que la DLL est cr��e dans les r�pertoires MaLib/release ou MaLib/debug, et parce que j'ai plusieurs programmes qui utilisent la DLL. Y'a pas un moyen plus pratique pour que les executables trouve leur bonne (debug/release) DLL? et donc sans avoir � d�placer manuellement la DLL dans chaque r�pertoire des ex�cutables.
Non. Par contre il vaut mieux d�finir le symbole dans les options du pr�processeur plut�t que dans le code source.Citation:
- Y a t-il un moyen de reconna�tre automatiquement (avec un #ifdef ?) , si le projet compile une DLL ou une LIB? Ca m'�viterait d'avoir � modifier manuellement l'ent�te de configuration � chaque changement de projet.
Pas � ma connaissance. Par contre selon ton environnement, tu peux ajouter un PATH temporaire pendant l'ex�cution de tes projets qui requierent la DLL, ou encore faire un .bat qui copie la DLL o� il faut, et ex�cut� automatiquement en �tape de post-build.Citation:
- Il faut que l'ex�cutable trouve la DLL. A ma connaissance, il faut donc que la DLL soit dans le m�me r�pertoire que l'executable ou bien dans l'un des r�pertoires du PATH. Mais ni l'un ni l'autre n'est pratique parce que la DLL est cr��e dans les r�pertoires MaLib/release ou MaLib/debug, et parce que j'ai plusieurs programmes qui utilisent la DLL. Y'a pas un moyen plus pratique pour que les executables trouve leur bonne (debug/release) DLL? et donc sans avoir � d�placer manuellement la DLL dans chaque r�pertoire des ex�cutables.
Je m'en doutais un petit peu...
Encore merci
J'ai parl� trop vite, car finallement le probl�me reste entier.
La DLL n'a certes pas de d�pendances, mais la librarie d'importation en a.
Je ne m'en suis pas rendu compte sur le coup car je travaille sous le m�me environnement (et les paths rendaient le probl�me transparent).
A moins de se passer de la librairie d'importation, avec des appels explicites � la DLL, je vois pas comment faire. Mais la syntaxe des appels explicites (GetProcAdresse) me para�t tellement contraignante que je d�sire � tout prix l'�viter.
Des id�es?
Normalement �a ne devrait pas �tre le cas. Les biblioth�ques statiques devraient �tre compil�es dans ta DLL et ne plus t'emb�ter. Peut-�tre une option de compilation � bidouiller ?
Ca se complique.
Je cerne un peu mieux le probl�me, mais c'est pas encore �a
En fait j'utilise STLport pour compiler ma librairie, car d'apr�s mes tests (qui datent certes un peu), celle-ci est plus rapide avec le compilo ICL que les STLs de VC ou de GCC pour les calculs math�matiques (en particulier sur les nombres complexes). Bref, j'utilise une librairie (statique ou dynamique, c'est selon) pour STLport.
Je me mets dans la peau d'un utilisateur lambda, sans STLport mais utilisant la STL int�gr�e � Visual.Je r�ussis � lier mon programme avec ma DLL, mais son lancement m'annonce qu'il lui faut imp�rativement la DLL de STLport. Donc il y a dor�navant une d�pendance dynamique (alors que la d�pendance �tait auparavant statique avec les LIB)
En plus, STLport � un comportement inhabituel pour lier la librairie (statique ou dynamique). Il n'est pas besoin de rajouter la d�pendance dans l'�dition de liens du projet comme d'hab.
En fait il y a a qq part dans un '.h' de STLport une instruction pour importer la bonne librairie. (j'ai pas encore d�nicher l'endroit dans le code. Vu que je connais pas l'instruction, c'est pas facile � trouver)
Ca me laisse penser qu'il existe bien une possibilit�, pour faire en sorte que le code C++ sache si le compilo est en mode statique ou dynamique)
J'ai raison?
Des pistes?
Donc, au final, dans le programme, std::complex vaudra des choses diff�rentes selon l� o� on se trouve ? C'est une violation de l'ODR, ce qui est un comportement ind�fini. En pratique, pour ce genre de manip, il faut surtout �viter par dessus tout que des variables de tous ces types soient pass� entre les deux bouts du programme.Citation:
Envoy� par Charlemagne
Oui, les DLL ne sont pas link�es... Puisque c'est tout leur int�r�t...Citation:
Envoy� par Charlemagne
Pourquoi ne pas utiliser des libs statiques ? Il me semble que dans les options de projet d'une biblioth�que statique visual C++, tu as un onglet nomm� Librerian qui te permet d'aggr�ger une autre biblioth�que statique avec la tienne. Il me semble que j'ai d�j� eu des surprises avec cet onglet, mais je ne sais plus lesquelles, et c'�tait � un moment o� j'avais pas eu le temps de prendre le temps de comprendre.
Regarde un truc genre #pragma comment (lib:...)Citation:
Envoy� par Charlemagne
Souvent, le compilatuer d�finira des macros pr�processeur (genre DLL).Citation:
Envoy� par Charlemagne
Il est tard, j'ai pas encore essay� tes propositions, mais ca devrait m'avancer s�rieusement.
Je n'avais pas pens� � ce probl�me �ventuel. Ca devrait pas �tre un probl�me pour les complexes dont le code est normalement int�gralement dans les '.h', � moins d'instanciations explicites dans la librairie STL. Mais la remarque est pertinente. Y'a surement quelques fonctions instanci�es (je pense aux entr�es-sorties), mais pour l'instant j'ai pas vu de doubles d�finitions lors de l'�dition de lien avec le programme utilisateur.Citation:
Donc, au final, dans le programme, std::complex vaudra des choses diff�rentes selon l� o� on se trouve ? C'est une violation de l'ODR, ce qui est un comportement ind�fini. En pratique, pour ce genre de manip, il faut surtout �viter par dessus tout que des variables de tous ces types soient pass� entre les deux bouts du programme.
Le probl�me sera peut-�tre plus flagrant avec ta proposition un peu plus loin d'aggr�ger des libs statiques.
Que faire si y'a des doublets lors de l'�dition de lien?
Ca aussi �a peut m'int�resser, si y'a pas de probl�me de doublets.Citation:
Pourquoi ne pas utiliser des libs statiques ? Il me semble que dans les options de projet d'une biblioth�que statique visual C++, tu as un onglet nomm� Librerian qui te permet d'aggr�ger une autre biblioth�que statique avec la tienne. Il me semble que j'ai d�j� eu des surprises avec cet onglet, mais je ne sais plus lesquelles, et c'�tait � un moment o� j'avais pas eu le temps de prendre le temps de comprendre.
Je connais pas cette posibilit� de fusionner des libs. Si �a marche, je l'adopte.
C'est l'option "additional dependencies" dans Liberian?
Je vais t�cher de voir �a demain.Citation:
Regarde un truc genre #pragma comment (lib:...)
Souvent, le compilatuer d�finira des macros pr�processeur (genre DLL).
Mes essais ne sont pas concluants, et donc j'ai encore des questions.
1)
J'ai pas trouv� le moyen de fusionner/aggr�ger des libs statiques. J'ai bien essay� l'option 'additional dependencies' dans l'onglet Liberian, pour inclure la librairie statique de STLport. Mais lors de l'�dition de lien du programme utilisateur, ma librairie impose encore la d�pendance envers la lib statique de STLport.
2)
C'est bien "#pragma comment (lib: )" pour importer des libs dans le code source.
Et j'ai effectivement trouv� la macro _DLL, d�finie par Visual lorsque le code g�n�r� est en "Multithreaded DLL" (/MD, /MDd).
Mais cette macro ne permet pas de savoir si le compilo g�n�re ou non une DLL. Car il est tout-�-fait possible de faire une librairie statique en MD !!!, comme il est possible de faire une librairie dynamique en MT/ML !!!
Je pense avoir une id�e de ce qu'est la g�neration single/muti threaded (ML/MT), mais je comprends donc plus � quoi sert le multithreaded DLL.
Pour ta question 2, c'est en fait � quel runtime on va lier ta biblioth�que. Ce runtime contient en gros la biblioth�que standard, et on peut l'avoir en version statique ou dynamique, en version monothread - plus rapide - ou multithread - quand on utilise les threads :aie: -
D�sol�, je ne peux pas vraiment t'aider, puisque comme je l'ai dit, je n'ai jamais vraiment utilis� ce truc. Peut-�tre permet-il juste d'�viter � l'utilisateur de devoir sp�cifier dans son projet qu'il a besoin de l'autre biblioth�que, mais ne permet pas d'�viter qu'elle soit fournie ?Citation:
Envoy� par Charlemagne
Le dernier conseil que je peux donner, c'est d'utiliser dumpbin.exe(http://msdn2.microsoft.com/fr-fr/library/756as972.aspx) pour deboguer les symboles pr�sents dans une lib.