Compiler libusb-win32 sous Visual C++

Version imprimable

Voir 40 message(s) de cette discussion en une page

10/06/2013, 09h33
ternel
Ca peut être le genre de situation où refaire le projet.

Je veux dire:
1. créer un nouveau projet C
2. recréer les fichiers un par un (en copiant le code)
3. vérifier les options générale de compilation
4. compiler
10/06/2013, 10h35
VincM

Citation:

Déjà : si ton VS est assez récent, il te grisera les lignes de précompilation qu'il ne lira pas (utile pour ton extern par exemple ! ).

Oui, en effet, j'y ai pensé et je n'ai pas trouvé de lien entre les parties grisées et mes erreurs dans la suite du programme (je revérifierai peut-être quand même...)

Citation:

Sur linux, la ligne serait

Ah oui, mais on m'a demandé de développé sous Windows et je suis loin de connaître Linux ;)

Citation:

Ainsi, les includes locaux sont recherchés dans le dossier courant ET dans include !

Il trouve bien les fichiers que je souhaite utiliser, ce problème là est réglé (ça en fait au moins un :aie:)

Citation:

Je ne pense pas que tu sois du genre à déclarer des structures vides...

Ah si si! C'est un de mes jeux favoris! Ca fait des lignes de codes en plus inutilement, ça m'occupe :mouarf: Trève de plaisanterie....

Citation:

EDIT : la remarque de leternel page suivante est aussi une très bonne idée pour savoir où l'on en est, et repartir sur des bases saines.

Citation:

Ca peut être le genre de situation où refaire le projet.

Je veux dire:

créer un nouveau projet C
recréer les fichiers un par un (en copiant le code)
vérifier les options générale de compilation
compiler

Je vais faire ça je crois alors... Je vous tiens au jus!
10/06/2013, 11h57
Metalman

Si j'ai mis l'exemple du linux et autre...
C'est justement pour que tu ne mettes pas les headers "non fournis par VS" avec ceux fournis avec VS !
Peut être que VS compile quelquechose d'autre, ou include quelquechose et il utilise tes headers au lieu de ce qu'il faut (très très très peu probable).

Enfin garder une installation propre de VS c'est toujours mieux, et c'est pour ça que je te disais de jouer un peu avec le menu "projet" et toutes ses options. :P

Je suis en train de suivre vos conseils et refaire un nouveau projet.

En ajoutant les fichiers un par un et en regardant avec quels header ils sont liés, je suis tombé sur ça:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #if IS_DRIVER #ifdef __GNUC__ #define OBJ_KERNEL_HANDLE 0x00000200L #include <ddk/usb100.h> #include <ddk/usbdi.h> #include <ddk/winddk.h> #include "usbdlib_gcc.h" #else #include <ntddk.h> #endif #else #include <windows.h> #endif
Tout ce qui est entre _GNUC_ et le #else apparaît en clair donc n'est pas utilisé. Ce qui revient à dire que ce n'est pas un driver.... Pas top quand on veut justement faire un driver!
Et du coup, je me demande si je n'aurais pas des erreurs qui pourraient être liées à ça. J'ai bien envie de forcer ce #if (et mettre windows.h en commentaire, VC va gueuler sinon!)

11/06/2013, 08h58
VincM
Ca avance, ça avance.... Mais ce n'est pas encore tout à fait ça...

Citation:

c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\libusb_dyn.c(28): error C2143: erreur de syntaxe*: absence de '{' avant '*'
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\libusb_dyn.c(29): error C2143: erreur de syntaxe*: absence de ')' avant '*'
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\libusb_dyn.c(29): error C2143: erreur de syntaxe*: absence de '{' avant '*'
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\libusb_dyn.c(29): error C2059: erreur de syntaxe*: ')'

Ca concerne les lignes suivantes:
Code:

1 2 typedef usb_dev_handle * (*usb_open_t)(struct usb_device *dev); typedef int (*usb_close_t)(usb_dev_handle *dev);
J'ai ce type d'erreurs à chaque fois qu'apparait usb_dev_handle, il est souligné en rouge (donc il ne trouve pas son proto et je le cherche!!).
Je me console en voyant que le nombre d'erreurs totales est bien moins conséquent qu'avant :mrgreen:

En fouinant sur le net, je vois des :

Citation:

struct usb_dev_handle;
typedef struct usb_dev_handle usb_dev_handle;

Dans un usb.h...

Alors comme tu travailles avec la version win32, pas sûr que ça te convienne... ^^'
Et je crois que cela te ferait revenir au "struct usb_dev_handle should contains at least 1 member" ou quelque chose du genre.

Mais en REFOUINANT sur google avec "usb_dev_handle win32", et en allant sur le repo principal.... haha !
Je vois ça, qui contient également (lignes 308 - 309) :
Code:

1 2 struct usb_dev_handle; typedef struct usb_dev_handle usb_dev_handle;
Mais SURTOUT ça, qui contient ce que l'on cherche (ligne 45 - 58) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 struct usb_dev_handle { int fd; struct usb_bus *bus; struct usb_device *device; int config; int interface; int altsetting; /* Added by RMT so implementations can store other per-open-device data */ void *impl_info; };
Je pense que tu devrais include usbi.h au .c qui te sort ta dernière erreur ! :D

11/06/2013, 09h56
VincM

Ah tu as été plus rapide que moi!

J'ai ajouté ce header puis compilé; j'ai eu des erreurs parce que pour Visual, interface doit être un mot réservé vu qu'il apparaît en bleu. Je ne sais pas à quoi il correspond (je m'y intéresserai peut-être plus tard si j'ai le temps) mais du coup je l'ai changé en inter et j'ai modifié les autres fichiers en conséquence.

Maintenant, c'est dans usbi.h que j'ai des erreurs du même type que précédemment. Vu qu'il appelle lusb0_usb, je vais aller fouiner dedans....

Code:

void usb_fetch_and_parse_descriptors(usb_dev_handle *udev);

Citation:

c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\usbi.h(66): error C2143: erreur de syntaxe*: absence de '{' avant '*'
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\usbi.h(66): error C2059: erreur de syntaxe*: ')'

Et note importante: vraiment merci pour le coup de main!!! :ccool:
11/06/2013, 15h56
VincM

Ca avance, ça avance :D

J'ai toujours des erreurs (celles dont je n'ai pas parlé et que je gardais pour la fin) mais ce ne sont que des "identificateurs non déclarés".

Ce n'est peut-être qu'un header auquel je dois modifier le nom des variables ou un fichier oublié... Je suis quasiment certain que le plus dur est fait maintenant!

Merci pour votre coup de main!! :ave:
11/06/2013, 18h10
Metalman

Recherche bien dans le dépôt de la libusb win32 les .h qui ont des noms "intéressants", et recherche dedans les variables/strcutures/autre...

Et au pire : google directement le nom des objets et 'libusb win32' ! xD
12/06/2013, 14h22
VincM

J'arrive bientôt au bout! J'ai trouvé un header qui me manquait, modifié un autre... (ma version de libusb ne doit pas complétement correspondre aux header de mon WDK)

Il n'y a plus que error.c qui génère des erreurs (un comble hein? :D )
Son code est dispo ici
Et ce que j'ai en erreurs:

Citation:

c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(115): warning C4996: 'strerror': This function or variable may be unsafe. Consider using strerror_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
c:\program files\microsoft visual studio 10.0\vc\include\string.h(157)*: voir la déclaration de 'strerror'
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(129): warning C4013: 'FormatMessage' non défini(e)*; extern retournant int pris par défaut
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(129): error C2065: 'FORMAT_MESSAGE_FROM_SYSTEM'*: identificateur non déclaré
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(129): warning C4013: 'GetLastError' non défini(e)*; extern retournant int pris par défaut
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(140): error C2065: 'ERROR_SUCCESS'*: identificateur non déclaré
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(140): error C2051: l'expression associée à case n'est pas une constante
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(142): error C2065: 'ERROR_INVALID_PARAMETER'*: identificateur non déclaré
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(142): error C2051: l'expression associée à case n'est pas une constante
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(144): error C2065: 'ERROR_SEM_TIMEOUT'*: identificateur non déclaré
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(144): error C2051: l'expression associée à case n'est pas une constante
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(145): error C2065: 'ERROR_OPERATION_ABORTED'*: identificateur non déclaré
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(145): error C2051: l'expression associée à case n'est pas une constante
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(147): error C2065: 'ERROR_NOT_ENOUGH_MEMORY'*: identificateur non déclaré
c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\error.c(147): error C2051: l'expression associée à case n'est pas une constante

J'ai regardé dans error.h, aucun nom qui ressemble de près ou de loin à ces erreurs (je les aurais modifié sinon) et je n'ai pas trouvé de fichier intéressant à include pour définir tout ça...

Concernant error.c, j'ai modifié le #if au début pour le forcer à voir un driver.

J'ai hâte de pouvoir compiler tout ça et avoir enfin un BSOD (un driver qui fonctionne du 1er coup? NAAAN!)
12/06/2013, 14h57
Metalman
Ligne 113 dans ton lien :

Code:

return strerror(usb_error_errno);

D'après ce lien, on voit que le prototype qui t'intéresse est le 1er :
Code:

1 2 3 4 5 errno_t strerror_s( char *buffer, size_t sizeInBytes, int errnum );
Et d'après ce lien, strerror fonctionne comme ceci :
Code:

1 2 3 char *strerror( int errnum );
Au final...
Tu devras sûrement faire quelque chose du genre :

Code:

return strerror_s("ERRNO : ", 8, usb_error_errno);

Ce n'est qu'un warning il me semble donc rien de grave ;)

EDIT : ...oui tout ça, ce n'est que le 1er warning useless :P
12/06/2013, 15h40
Médinoc

Franchement, pour strerror(), tu auras plus vite fait avec un #define _CRT_SECURE_NO_WARNINGS plutôt qu'à te laisser entraîner par Microsoft dans du code non-standard.

Pour FormatMessage(), c'est qu'il manque l'inclusion de <windows.h>.

Citation:

Envoyé par Metalman

Ce n'est qu'un warning il me semble donc rien de grave

Oui, je pensais me pencher dessus à la fin....

Citation:

Envoyé par Médinoc

Pour FormatMessage(), c'est qu'il manque l'inclusion de <windows.h>.

Je veux bien ajouter <windows.h> mais initialement, j'ai le code suivant:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #if IS_DRIVER #ifdef __GNUC__ #define OBJ_KERNEL_HANDLE 0x00000200L #include <ddk/usb100.h> #include "usb100.h" #include <ddk/usbdi.h> #include <ddk/winddk.h> #include "usbdlib_gcc.h" #else #include "ntddk.h" #endif #else #include <windows.h> #endif
Lorsque <windows.h> est inclu, c'est que ce n'est pas un driver. Si c'est un driver, ce sont les autres header qui sont ouverts, non?
En laissant ce code tel quel, c'est windows.h qui est ouvert; j'ai donc forcé à considérer que c'est un driver (mon but final est quand même de faire un driver), donc windows.h n'est pas pris en compte.
Après, il y a peut-être un truc qui m'échappe.

J'ai quand même essayé de faire comme tu me l'as dis et j'ai des erreurs de linkage. Autrement, les autres ont disparues :ccool:

EDIT: petite question en plus, ntddk.h et windows.h ne peuvent jamais être utlisé ensemble, non?

EDIT2:
Ces erreurs de link m'embêtent aussi... Un exemple de ce que j'ai:

Citation:

install_filter_win.obj : error LNK2005: _info_text_0 déjà défini(e) dans inf_wizard.obj
install_filter_win.obj : error LNK2005: _g_hInst déjà défini(e) dans inf_wizard.obj
install_filter_win.obj : error LNK2005: _tooltips_dlg1 déjà défini(e) dans inf_wizard.obj
...
LINK : warning LNK4031: aucun sous-système spécifié*; CONSOLE pris par défaut
driver_registry.obj : error LNK2001: symbole externe non résolu __imp__ExAllocatePoolWithTag@12
driver_registry.obj : error LNK2001: symbole externe non résolu __imp__ExFreePoolWithTag

Vu qu'il me dit que certains sont définis dans plusieurs .obj, je me suis dit que j'allais enlever des objet... Ah ben ça fonctionne encore moins bien :pastaper:

13/06/2013, 11h47
Médinoc

Dans ce cas, il y a clairement un problème dans error.c: Un driver ne peut pas utiliser une fonction Win32 comme FormatMessage()...
13/06/2013, 11h53
VincM

Je me disais bien aussi qu'il y avait un truc bizarre....

EDIT: j'ai réfléchi un peu à midi et il n'y a peut-être pas de problème dans error.c en fait. Une fois terminée, libusb est censée donner un exécutable qui détecte les périphériques connectées et on choisit celui pour lequel on veut générer un driver. Ce n'est donc pas seulement un driver...
14/06/2013, 14h33
VincM

Après de multiples recherches, je touche presque au but!!! :aie:
Une seule erreur persiste!

Citation:

------ Début de la génération*: Projet*: DriverBis, Configuration*: Release Win32 ------
LINK : fatal error LNK1181: impossible d'ouvrir le fichier en entrée 'usb.lib'
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

Au départ j'ai cru qu'il n'arrivait pas à lire le fichier. Mais c'est en entrée que ça cloche en fait... C'est à dire?
14/06/2013, 14h48
Metalman

Tu as dû mal placer ton usb.lib il me semble...
Tu l'as bien indiqué dans ton projet comme étant une lib externe à utiliser ?
14/06/2013, 14h55
VincM

C'est ce que je pensais aussi mais il est placé avec les autres. :koi:

Je l'ai ajouté aux dépendances supplémentaires... Je vais chercher s'il n'y a pas un truc qui s'appelle "dépendances externes" ou quelque chose dans le genre.
14/06/2013, 15h05
Metalman

Je n'ai pas de VS sous la main où je suis actuellement, mais voilà de la doc :
http://msdn.microsoft.com/fr-fr/libr...=vs.80%29.aspx

C'est dans le dernier chapitre "Utilisation des fonctionnalités de la bibliothèque statique dans l'application console" que tu devrais avoir une explication sur ce que tu dois faire.
Dans ton cas, vu que c'est le linker qui râle, il n'y a aucun code à modifier, juste la référence au .lib à ajouter.
14/06/2013, 16h49
VincM

Histoire de partir en week-end frustré, le client à qui était destiné le projet a revu son cahier des charges et du coup j'ai bossé sur tout ça pour rien.... Je crois que le pire, c'est que ça arrive alors que j'arrivais au bout....:arf:

En tout cas, merci à ceux qui m'ont apporté leur aide pour ce programme! :ccool:
Lundi après-midi, j’essaierais de le faire compiler au moins pour ma satisfaction personnelle

Voir 40 message(s) de cette discussion en une page