Erreur de compilation suite à un portage Linux -> Windows

Version imprimable

29/09/2005, 17h00
Clément_R

Erreur de compilation suite à un portage Linux -> Windows

Bonjour à tous,

Dans le cadre d'un projet OpenSource multiplateforme, je dois porter mon code sous windows ( j'utilise Visual C++ 6.0 et Qt-3.3.5 pour Win ). Tout ce compilait très bien sous Linux et ( sous windows ), mais là, suite à un :

#include <windows.h>

J'en ai besoin pour un appel à "shellExecute" afin de pouvoir ouvrir un explorer ou lecteur de médias ou un module de mail.
mon programme ne veut plus compiler. J'obtiens les 2 erreurs suivantes dans un fichier header de Visual :

C:\Visual\VC98\INCLUDE\objidl.h(6624) : error C2143: syntax error : missing ';' before 'string'
C:\Visual\VC98\INCLUDE\objidl.h(6624) : fatal error C1004: unexpected end of file found

Les lignes correspondantes sont fournies avec Microsoft Visual studio... Donc je pense ( peut-etre à tord, mais j'en aurais entendu parler ) que ces lignes sont plus "sûr" que les miennes.
Il ne manque pas à mon code ';' ni de '(' ou ')' . Ca fait maintenant + de 3 jours à temps plein que je suis la-dessus... Si quelqu'un avait une idée ce serait super super gentil... :lol:
Parce que là moi je CRRAAAQUE ... :cry: :cry:

D'avance, merci beaucoup.

Clément

PS : C'est mon premier message sur un forum, alors excusez moi si je ne l'ai pas mis dans la bonne thread...
29/09/2005, 17h48
Jan Rendek

Est-tu sûr que 'string' est correctement défini ?
Le "missing ';' before 'string' " sent fort la déclaration de type manquante.
29/09/2005, 17h57
Clément_R

Citation:

Envoyé par VoidSeer

Est-tu sûr que 'string' est correctement défini ?
Le "missing ';' before 'string' " sent fort la déclaration de type manquante.

Bien non, je n'en suis pas sûr, mais je ne m'en serts pas; à aucun endroit de l'appli. J'utilise exclusivement : des QString et des char[] (encore qu'assez peu pour ces derniers).
De même je ne fais appel ( hormis peut être indirectement à cause de Libxml et Libxslt que j'inclus ) à aucune methode ou classe des stdlib .
29/09/2005, 18h11
Laurent Gomila

Et à tout hasard, il y a quoi à la ligne 6624 de ce fichier ?
29/09/2005, 18h13
Jan Rendek

Difficile de t'aider à distance sur un coup comme ça.
Je pense que le plus simple, c'est d'isoler la partie de ton code qui nécessite les en-têtes de
window.h. Au pire, commenter les fonctions en question. Le but est de voir quel fichier
d'entête provoque l'erreur, ou quelle succession de fichiers d'entête provoque l'erreur.

Ensuite, si tu n'as besoin que de très peu de fonctionnalité de windows, essaie de retrouver
les fichers strictement nécessaire à tes besoins. Quand tu inclues windows.h, tu inclues
en cascade un ensemble assez conséquent de fichiers, dont tu n'as sûrement pas besoin
(notamment objidl.h, je pense).

Sinon, au petit bonheur la chance, j'essaierais un #include <string> avant d'inclure windows.h

L'erreur "fatal error C1004: unexpected end of file found " est génante tout de même. Est-tu
sûr que tu n'as pas oublié de point-virgule après la déclaration d'une classe ou d'une structure ?

Voilà mes 2 cents d'euros. Je laisse les spécialistes windows te répondre plus avant.
29/09/2005, 18h25
Clément_R

Citation:

Envoyé par Loulou24

Et à tout hasard, il y a quoi à la ligne 6624 de ce fichier ?

Alors à la ligne 6624 du fichier objidl.h, il y a ça :

/****************************************
* Generated header for interface: IDataObject
* at Thu Sep 11 10:57:04 1997
* using MIDL 3.03.0110
****************************************/
/* [unique][uuid][object] */
typedef /* [unique] */ IDataObject __RPC_FAR *LPDATAOBJECT;
typedef
enum tagDATADIR
{ DATADIR_GET = 1,
DATADIR_SET = 2
} DATADIR; // ligne 6624
EXTERN_C const IID IID_IDataObject;
#if defined(__cplusplus) && !defined(CINTERFACE)
.
.
.

Le fichier est installé nativement avec MS Visual, je dois avouer qu'hormis la définition d'une structure, je n'y comprends pas grand chose... :roll: :oops:
Je suppose (très fortement) que les erreur viennent de mon code ou de la configuration VC++ de mon projet et pas de ces lignes qui après tout doivent être bonnes.

Le fait étrange est que si je retire l'appel à shellExecute, j'ai toujours les 2 erreurs, elles sont générées à cause de ce #include. Je soupsonne donc un problème de conflit de lib, mais je ne maitrise pas assez ( ni visual, ni la prog sous win ) pour pouvoir le déterminer autrement que de façon empirique ( c a d : dégager les lib les unes après les autres en croisant les doigts pour que ça marche )...

Merci de m'aider :D
29/09/2005, 18h31
Jan Rendek
Ce n'est pas un problème de lib, puisque le build échoue avant l'édition de liens.
Recherche dans quel fichier d'entête est déclaré la fonction 'shellExecute()' dont tu as besoin,
et inclue uniquement celui-ci.
Vérifie aussi tes propres fichier d'entête. Le plus simple c'est de faire un programme bidon
Code:

1 2 3 4 5 6 #include "le_fichier_a_tester.hh" int main() { //EMPTY }
Tu les passes un par un, comme ça tu verras s'il manque un point-virgule, ou autre chose.
29/09/2005, 20h27
Clément_R

ENNNNNFFFIIIINNNNNN !!!!!!!!

:idea: Ôh Gloire ! Ôh bonheur ! :D

Ca y est je l'ai localisé !!! On dit quoi ? On dit :" merci Microsoft !" :?
Désolé pour les adorateurs de Bill ( je n'ai rien contre lui mais quand même )... J'ai encore jamais eut ce genre de trucs sous Linux. :twisted:

Bref toujours est-il l'erreur de compilo venait de, attention les yeux :

#define DATADIR "/usr/share" 8O

Donc c'est à savoir ce n'est la chaine de caractère qui fait référence à un chemin sous Linux qui faisait planter la compilo sous windows. Mais bien le nom de ma MACRO. C'est vrai, je le reconnais c'est un nom de macro pourri ( qui est surtout potentiellement utilisé partout ), mais bon c'est PAS UNE RAISON...
Donc, surtout si vous avez besoin d'un header découlant d'un :
#include <windows.h>
, prenez garde de ne pas avoir déclaré de macro
ayant le model suivant :
#define DATADIR "ma_macro_blablabla"

Sinon vous savez ce qu'il vous attend...
Donc voilà...

Clément

PS : merci VoidSeer pour ton idée ( c'est elle qui m'a sauvé ) et un peu de chance...
PS 2 : je crois que ça ne se fait pas de s'adresser directement comme ça à un gars ( ou une fille d'ailleurs ) dans les forums, mais quand même... Merci VoidSeer :twisted:
29/09/2005, 20h55
Laurent Gomila

Effectivement Microsoft "pourrit" parfois l'espace global avec ses macros (compatibilité C oblige), mais toi rien ne t'empêche d'utiliser des espaces nommés et des constantes au lieu de ces horribles #define :wink:
29/09/2005, 21h20
Médinoc

Et puis, dans les cas où quelque chose perturbe windows.h, il reste également la possibilité de l'inclure AVANT le #define...

Là, le compilateur aurait surement marché correctement, puisque DATADIR est un typedef et que tu ne l'utilises pas. (si DATADIR était une définition, il y aurait eu une erreur de redéfinition de macro...)
30/09/2005, 11h11
Aurelien.Regat-Barrel

Citation:

Donc c'est à savoir ce n'est la chaine de caractère qui fait référence à un chemin sous Linux qui faisait planter la compilo sous windows. Mais bien le nom de ma MACRO. C'est vrai, je le reconnais c'est un nom de macro pourri ( qui est surtout potentiellement utilisé partout ), mais bon c'est PAS UNE RAISON...

Ben si, c'est le comportement attendu. Le compilo n'a pas planté, il n'a fait qu'exécuter ce que tu lui a demandé, à savoir de remplacer partout dans le code le mot DATADIR par l'expression "/usr/share".
30/09/2005, 12h50
Caine

Avant de critiquer Windows à tout va, il faut savoir ce que signifie un portage d'un OS vers un autre.

Un portage réussi, ça ne s'invente pas et ça demande de maîtriser les deux OS.
30/09/2005, 15h45
Matthieu Brucher

Et c'est pas dû à Microsoft, c'est dû à ton code.
14/10/2005, 11h01
Clément_R

Citation:

Envoyé par Caine

Avant de critiquer Windows à tout va, il faut savoir ce que signifie un portage d'un OS vers un autre.

Un portage réussi, ça ne s'invente pas et ça demande de maîtriser les deux OS.

Non effectivement, ça n s'invente pas. Mais quand t'es payé pour le faire, tu t'exécutes comme tu peux... :cry: