Discussion :

[Pierre.g]

Bonjour tout le monde,

L'origine de mon problème : Je veut utiliser une fonction qui n'est pas dans les headers de MinGW ni apparemment dans sa librairie (libadvapi32.a) qui ne doit pas être à jour.

Donc, j'ai déclaré le prototype de la fonction, mais à la compilation j'ai un message d'erreur comme "undefined reference to `xxxxxxxx@8'" et j'ai remarqué que le compilateur renvoyais ce genre de message avec [nom de la fonction]@[nombre] quand on avait oublié de lier une librairie.

Le problème, c'est que j'ai déjà lié libadvapi32.a qui se trouve dans le dossier de MinGW, donc j'en ait conclus que comme la fonction n'étais pas dans les headers, elle n'avait pas non plus été inclus dans la librairie de MinGW.

Donc j'ai chargé le SDK de XP SP2, et dedans j'ai trouvé la librairie Advapi32.lib, mais le problème c'est que les librairies données par le SDK de Microsoft ne sont pas compatibles avec MinGW.

Donc j'ai plusieurs question :
1- Est-ce que mon résonnement est bon ?
2- Peut-on compiler ou convertir une librairie .lib en .a ?
3- Sinon, peut-on prendre le code source qui a été utiliser pour générer le .a et y ajouter ce qu'il faut pour cette fonction ?
4- Peut-on "dire" au compilateur "fait comme si tu avait trouvé ce qu'il faut dans libadvapi32.a", et ensuite le programme devrait fonctionner normalement puisque la fonction existe dans la dll vers laquel la librairie renvoyais ?
5- En dernier recours, j'ai crus comprendre qu'il y avait une autre manière de lier une dll à un .exe, vous pouvez m'en dire plus ?

Merci.
A+, Pierre.

[hegros]

Bonjour

Le sujet est un peu complexe mais je tente de t'apporter quelques réponses :

2- Peut-on compiler ou convertir une librairie .lib en .a ?

Je ne sais pas par contre pour moi .lib et .a désigne la même chose.

3- Sinon, peut-on prendre le code source qui a été utiliser pour générer le .a et y ajouter ce qu'il faut pour cette fonction ?

Théoriquement oui.

4- Peut-on "dire" au compilateur "fait comme si tu avait trouvé ce qu'il faut dans libadvapi32.a", et ensuite le programme devrait fonctionner normalement puisque la fonction existe dans la dll vers laquel la librairie renvoyais ?

Dans ce cas il ne faut pas faire mention de façon explicite dans le code de l'appel à la fonction de la dll.Pour exemple en chargant la DLL dynamiquement combiné à GetProcAdress(sous windows) cela devrait fonctionner.

5- En dernier recours, j'ai crus comprendre qu'il y avait une autre manière de lier une dll à un .exe, vous pouvez m'en dire plus ?

Mise à part le fait de récupérer un pointeur sur fonction (exemple de GetProcAdresse) je ne vois pas comment.

[Médinoc]

J'ai lu quelque part sur le forum, qu'en fait, les .a de MinGW seraient précisément au même format que les .lib, et serait donc compatibles.

J'ignore si c'est vrai ou non, mais tu peux toujours essayer de renommer advapi32.lib en libadvapi32.a...

Si ça ne marche pas, il faudra se rabattre sur la liaison explicite, à coups de LoadLibrary() et GetProcAddress()...

[Pierre.g]

Ça y est, j'ai résolu mon problème.

D'abord, comme je pensais que c'étais le .a de MinGW qui n'étais pas assez complet, j'ai chargé les sources des .a, je les ais recompilé (avec dlltool.exe) puis j'ai vu que finalement la fonction que je voulais y étais incluse.

J'ai ensuite regardé pour une nième fois le header de MinGW qui contenais le prototype de la fonction, et je ne comprenais pas pourquoi ça ne marchais pas, j'ai donc baladé un #error pour m'apercevoir qu'il fallait définir la variable de préprocesseur WINVER à 0x0500 pour qu'il puisse inclure ce qu'il faut ... et la tout marche !

Donc maintenant deux questions :
1. Est-ce que ça peut me poser un problème plus tard si je modifis la valeur de WINVER dans windef.h ?
2. Existe-il un moyen de dire au compilo de ne pas afficher certains warning spécifique ? (par exemple pour une certaine ligne ?)

PS : j'ai essayé, les .lib donnés avec le SDK de Microsoft ou autre ne sont pas compatibes (même renomés) avec MinGW.

Merci.
A+, Pierre.

[Médinoc]

1. DANS winddef.h ? J'en ai peur. Modifie-la plutôt avant tes includes, ou dans les options de la ligne de commande...
2. Sous Visual, oui (#pragma warning). Sous GCC, ça m'étonnerait, d'autant que les warnings n'ont même pas de N°...

[hegros]

Normalement tu ne devrais pas modifier des fichiers d'entête(sauf cas exceptionnel)
A quoi correspond WINVER = 0X0500 et qu'est-ce que cela valait avant ?

[Pierre.g]

OK, merci, le pragma marche aussi pour GCC, par contre, apparemment il ne marche que dans les headers et est limité au header dans lequel il à été inclus :

Code :

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

#pragma GCC system_header

WINVER = 0X0500 correspond à Windows XP, et WINVER est définis à 0x0400 dans les headers de MinGW (soit Windows 2000 je crois).

Sachant que la fonction (ConvertSidToStringSid) pour laquelle le header en question (sddl.h) demande que WINVER soit à 0x0500 est compatible avec Win 2000 (0x0400), je pense qu'on peut appeler ça un bug ...

Je viens de voir que dans windef.h il est précisé :

Code :

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

1
2
3
4
5
/*
 * If you need Win32 API features newer the Win95 and WinNT then you must
 * define WINVER before including windows.h or any other method of including
 * the windef.h header.
 */

Je viens aussi de découvrir la directive préprocesseur #undef, donc je vais redéfinir WINVER dans mon code pour ne pas avoir à trifouiller les headers à chaque réinstallation de MinGW, et mettre #undef WINVER avant pour ne pas avoir de warning inutiles.

Voilà.

Merci et à la prochaine.
Pierre.

[Médinoc]

Tu ne devrais pas t'amuser avec WINVER après les headers, ça ne sert à rien.
Je te conseille de mettre directement WINVER et _WIN32_WINNT sur la ligne de commande.

[Pierre.g]

Sur la ligne de commande ?

Tu veut dire la ligne de commande pour appeler le compilateur ?
Si oui, j'utilise un EDI, donc c'est lui qui s'occupe d'appeler le compilo.

J'ai redéfinis WINVER juste avant d'appeler sddl.h qui est le dernier header que j'inclus, ça ne pose pas de problème normalement.

Tu pense que c'est une mauvaise habitude à ne pas prendre ?

[Médinoc]

Oui.
Et dans ton EDI, tu as des options pour définir les macros que tu veux sur la ligne de commande.
Dans Dev-C++, tu peux ajouter les paramètres que tu veux à GCC, soit dans les options du projet, soit dans les options de l'EDI.
Dans Visual, c'est dans Project Properties -> Configuration Properties -> C/C++ -> Preprocessor
Dans Code::Blocks, je ne sais pas où c'est.

[rigobert]

OK, merci, le pragma marche aussi pour GCC, par contre, apparemment il ne marche que dans les headers et est limité au header dans lequel il à été inclus :
WINVER = 0X0500 correspond à Windows XP, et WINVER est définis à 0x0400 dans les headers de MinGW (soit Windows 2000 je crois).

Sachant que la fonction (ConvertSidToStringSid) pour laquelle le header en question (sddl.h) demande que WINVER soit à 0x0500 est compatible avec Win 2000 (0x0400), je pense qu'on peut appeler ça un bug ...

Non :

- WINVER = 0x0400 cible au moins 95/NT4
- WINVER = 0x0500 cible au moins Me/2000

Lire les docs avant de crier au bug !

[Pierre.g]

OK, merci Médinoc.

"Lire les docs avant de crier au bug !"
=> j'étais pas bien sur de mon coup ... comme XP est la série 5, je pensais que la série 4 étais 2000 ... finalement non.