Discussion :

[r0d]

Bonjour à tous,

En près de 10 ans d'utilisation de VS, c'est la première fois que je vois cela, et vraiment ça me dépasse:
Dans une solution, j'ai 2 projets. Le premier est compilé en tant que dll qui va être utilisée par le second. Normalement, et jusqu'à hier, lorsque je compilais le premier, il me générait un .dll et un .lib. J'ai dû modifier quelque chose (bien que je ne crois pas avoir modifié quoi que ce soit mais je ne crois plus au code qui se modifie tout seul), et maintenant il ne me génère que la dll. Or le second projet a besoin du .lib pour linker.

J'ai fais mille fois le tour de mes options de compilation, et tout me semble nickel. Par exemple, dans linker -> avanced -> import lib, j'ai même mis le chemin en dur (c:/path/sans/espaces/malib.lib).

Avez vous une idée, un indice, sur ce qu'il peut se passer?

edit: il s'agit de visual 9 (ou visual 2008) pro SP1, sous windows XP

[camboui]

Aucune idée, juste des pistes.
Regarde mon sujet "runtime error avant main" d'il y a quelques jours dans ce même forum.
Un collègue a eu une blague du genre quelques semaines plus tôt (voir KB971090).

En bref, MS fait des patchs parfois déroutants.
Essaie en faisant un "rebuild all", en effaçant tous les répertoires release et debug, etc. Bien que je suppose que tu aies déjà essayé tout cela.

[3DArchi]

Salut,
Le seul cas dont je me souvienne est la création d'une DLL dans laquelle aucun symbole n'était exporté : ni fonction, ni classe. Alors, la DLL est bien créée mais pas de .lib.

[r0d]

rôôô, j'ai trouvé le problème. En récupérant une ancienne version et en comparant les options de compilations, et le problème venait d'une variable de précompilation que j'avais enlevé. Je l'avais enlevé car je ne savais pas à quoi elle servait (et je ne le sais toujours pas d'ailleurs, je vais chercher ça tout de suite). La variable est de cette forme: __EXPORT_MON_PROJET_DLL__
Et effectivement, si cette variable n'est pas définie, le .lib n'est pas généré. Je ne sais pas d'où vient cette variable (c'est un projet que j'ai récupéré "en route"), et elle n'est utilisée nulle part dans le code.
C'est ce qui m'ennuie un peu parfois dans Visual, il fait trop de choses "dans notre dos".

[3DArchi]

Je pense que c'est ce que je disais : tu n'avais aucun symbole exporté. La macro __EXPORT_MON_PROJET_DLL__ est souvent employée pour différencier le header selon qu'on génère la DLL ou qu'on importe l'interface de la DLL dans un projet. C'est en général quelque chose qui ressemble à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifdef EXPORTER
#define __EXPORT_MON_PROJET_DLL__ __declspec(dllexport)
#else
#define __EXPORT_MON_PROJET_DLL__ __declspec(dllimport)
#endif

et ensuite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class __EXPORT_MON_PROJET_DLL__ blabla{
// ...
};
__EXPORT_MON_PROJET_DLL__ void __cdecl re_blablabla();

La définition des macros de type __EXPORT_MON_PROJET_DLL__ peut plus ou moins varier selon les configurations gérées ou les compilateurs pris en compte, mais on retrouve toujours au - une définition avec dllexport et une avec dllimport pour visual.

[Mac LAK]

Par défaut, cette définition de préprocesseur s'appelle <NOMDUPROJET>_EXPORTS, et la macro d'exportation / importation à insérer dans le code s'appelle <NOMDUPROJET>_API. Par habitude, je ne change jamais ces noms par défaut de façon à garder une cohérence générale entre mes projets.

Si la macro est absente, ça ne produit en général que des emm.... : soit tu ne génères que la DLL (avec une erreur de link derrière), soit que la librairie d'importation (avec une belle erreur à l'exécution bien sûr).