cool… :aie:
Version imprimable
cool… :aie:
VDM :(
J'apprends le métier de développeur :aie:
Alors que mon domaine est le hard...
En effet c'est très moche....
Mais le résultat m'intéresse tout de même ! :)
Bon courage pour la suite !
Je posterai lorsque j'aurais réussi à compiler ;)
Je poste mais je n'arrive toujours pas à compiler :aie:
Je n'ai plus d'idée pour le forcer à compiler là, il me nargue en affichant toujours le même message:
J'ai été dans propriétés -> Editeur de lien-> Général -> Répertoires des bibliothèques supplémentaires, rien ne change...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é ==========
J'ai fait propriétés -> Editeur de lien -> entrée -> dépendances supplémentaires, là encore ça ne change rien...
Dans la ligne de commande, j'ai essayé /FORCE usb.lib, toujours rien!
J'ai essayé /LIBPATH usb.lib aussi, comme dit ici...
....je vous laisse deviner le résultat...
Et tout les fichiers sont correctement placés dans leur dossier et tout....
Tu as regardé ce que dit MSDN??
J'avais trouvé l'équivalent en anglais ;) ...à part pour les espaces, mais c'est une chose à laquelle je fais gaffe.
Comme les corrections classiques ont été proposées, je ne vois pas que dire de plus
Dans le doute que ça puisse être un bug de Visual, j'ai tenté ce matin de faire un nouveau projet mais je me retrouve avec le même soucis.
Je suis sûr que c'est une configuration de Visual à modifier au moins.
Après moult bricolages, des crampes aux doigts et les yeux tout rouge, je crois que j'ai viré la dernière erreur.... (me demandez pas comment j'ai fait, je cherche encore... :mrgreen:)
...mais elle a laissé place à d'autres! :aie: (dans le même genre qu'avant)
Je mets le rapport complet.... (ouch, du lourd!!!)
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
Je vois deux classes d'erreurs: Des définitions multiples (compilerais-tu des fichiers sources qui s'incluent les uns les autres, ou quoi?) et des fonctions dllimport non trouvées (apparemment tu oublies de lier à NTOSKrnl.lib)
Il y a aussi LINK : warning LNK4031: aucun sous-système spécifié*; CONSOLE pris par défaut à voir; tu es censé lui dire sur quel sous-système tu travailles, même si c'est "aucun" (driver).
les causes probables d'une définition multiples sont:
- Présence d'une définition non inline dans un en-tête (inclus plusieurs fois). solution? rejeter la définition dans un fichier d'implémentation (.c) ou inline-er
- Inclusions du même fichier d'objet compilé (.o) dans l'édition de lien. solution? ne pas le faire, en nettoyant le fichier de projet
C'est vrai que j'ai pas pensé à vérifier si des sources s'incluaient mutuellement... Ca serait bien tordu quand même! :koi:Citation:
Envoyé par Médinoc
Par contre j'ai des en-têtes qui en appellent d'autres, rien de dérangeant à cela?
Quand j'essaie d'ajouter ntoskrnl.lib, le compilateur me dit qu'il n'arrive pas à l'ouvrir.Citation:
Envoyé par Médinoc
EDIT: Quel idiot! En le plaçant dans le bon dossier, ça va déjà mieux :roll:
N'oublie pas de protéger tes headers !
fichier_1.h :
A faire dans chacun de tes .h !Code:
2
3
4
5
6
7
8
9
10
11
12
EDIT : et il vaut mieux éviter d'inclure des .c entre eux...
Chaque .c inclue un ou des .h qui incluent eux-même des .h uniquement !
Et tous les .h sont protégés !
il faut bien comprendre que #include est une commande pour le préprocesseur.
Ca correspond plus ou moins à copier coller le contenu du fichier désigné puis de continuer à préprocesser (par la premiere ligne du fichier inclus, du coup)
Je viens de finir de le faire. La plupart l'était déjà en fait. Je m'attaque maintenant aux erreurs de link.Citation:
Envoyé par Metalman
L'erreur LNK2005 est-elle possible si on a une fonction qui est déclarée dans un .c ET dans un .h que ce même point .c appelle?
Par exemple:
Code:
2
3
4
5
Apparemment j'aurais des trucs comme ça.Code:
2
3
4
5
6
Dans les .h tu ne dois avoir QUE les les "signatures" de fonctions !
Et dans les .c tu les implémentes !
Et attention aussi : si tu modifies les .h et leurs ordres d'inclusion, il faut assez souvent faire un clean du projet et recompiler.
(C'est surtout que si tu modifies localement un .c, il sera automatiquement recompilé, mais pas toujours pour les .h)
Bref, la signature (dans le .h) d'une fonction c'est simplement :
Et dans le .c tu auras :Code:
2
3
4
5
6
7
8
9
10
Tu peux (et doit) avoir cela pour les fonctions exportables.Code:
2
3
4
5
6
Pourquoi ?
Comme tu vas inclure les .h entre eux, les sources ayant besoin de fonctions présentes dans d'autres .c vont automatiquement comprendre qu'elles ne trouvent pas le code, mais qu'il sera mis lors de la phase de link !
C'est en rapport avec la règle de la définition unique (one definition rule ou ODR).
Pour bien comprendre, il faut comprendre la différence entre déclaration et définition.Citation:
Toute chose utilisée doit être définie une et une seule fois.
Une déclaration dit au compilateur "je sais que ceci sera défini, ne t'inquiète pas".
Une définition lui dit au contraire "Voici la définition de cette chose à utiliser pendant l'édition de lien".
Pour la compilation, et l'édition de lien, il n'y a que le concept de symbole. Un symbole à un genre parmi: type, variable, fonction, espace de nom et littéral.
Chacun à sa forme de déclaration et de définition.
En gros, les définitions ont les formes suivantes:
- struct t{/**/}; ou typedef type nom; ou encore using nom = type;
- int i;
- void f(int a){/**/}; (ici, "int a" est aussi une définition)
- namespace truc {/*contenu*/}
- 2, '2', "phrase"
Les déclarations, qui ne créent pas de symbole complet:
- struct t;, t est alors un type incomplet, utilisable en l'état uniquement pour déclarer des pointeurs ou références.
- external int i; (surtout, pas de valeur)
- void f(int a); (ici, "a" est un commentaire, et int fait parti de la déclaration de f)
- déclarer un namespace n'a pas d'intérêt, mais je crois que ca serait namespace truc;
- rien pour les littéraux.
Tu peux déclarer les choses autant de fois que tu veux, mais une seule définition est autorisée:
Code:
2
3
4
5
6
7
8
9
Malgré mon tout petit niveau de programmeur en C, c'est toujours ce raisonnement que je suis. Mais rentrer dans les détails ne fait pas mal et ça me permet mieux comprendre. :)
Apparemment, les programmeurs du code que j'ai récupéré ne sont pas aussi friands de ces règles de base :lol:
Bon, je retourne à mon rapport d'erreurs; c'était mes 2min de relaxation sans C (ou presque)
Je viens de tomber sur ça sur le mdn.
Surtout sur:
"L'appel d'une fonction C depuis un programme C++ sans utilisation de extern "C" (qui impose au compilateur d'utiliser la convention de noms C) peut causer LNK2001. Les options du compilateur /Tp et /Tc font compiler les fichiers sous forme C++ ou C, respectivement, quelle que soit l'extension du nom de fichier. Ces options peuvent causer des noms de fonctions différents de ceux attendus."
Si un code est déjà en C et qu'il n'y a pas extern "C", vous pensez que cette erreur peut apparaître?
Tu as des fichiers "uniquement" composés de C ?
Pas de "class" ou autre ?
Si aucun "class" ni de .cpp : alors pas besoin de "extern".
EDIT : j'ai peut être oublié le cas des .lib
Ce mot du langage sert en fait lors de la transformation du C++/C vers le langage intermédiaire (avant l'assembleur) : en C, un nom de fonction == une fonction, en C++ par contre, une fonction == un nom de fonction + un type de retour + des paramètres + types des paramètres.
Le compilateur va créer des noms de fonctions "internes" contenant toutes ces informations.
Tu te doutes "du coup", que mettre du C et du C++ va entraîner des problèmes de link : le C n'utilisera QUE le nom dans les déclarations de fonctions dans les .o, et C++ va chercher un autre nom composé des types etc... ce qui créera des "undefined reference to..."
EDIT : là je n'ai expliqué que pour le cas C/C++, mais il y a encore plus tordu avec les conventions d'appels (en parcourant en diagonal ton lien ;P).
En cdecl, stdcall, etc... d'autres trucs comptent : dans l'un c'est l'appelant qui pousse les arguments sur la pile, et la nettoie au retour, dans l'autre c'est l'appelé qui le fait !...
Bref...
Par contre j'ai un doute si on appelle depuis un .lib
J'ai résolu 2 erreurs de link! 2 fichiers sources qui utilisaient des mêmes noms de fonction.
Maintenant j'ai droit à:
Et la fonction qui va bien:Code:c:\winddk\7600.16385.1\src\driver\driverbis\driverbis\install_filter_win.c(683): error C2040: 'create_tooltip'*: les niveaux d'indirection de 'HWND (HWND,HINSTANCE,UINT,create_tooltip_t *)' et de 'int ()' sont différents
J'ai été voir sur le msdn pour me renseigner un peu plus sur cette erreur mais c'est pas terrible. Et google ne m'a beaucoup aidé non plus...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
C'est une erreur dans la fonction, de l'appel de la fonction ou...??
Il se plaint que tu passes un pointeur vers create_tooltip() à quelque chose qui semble attendre un pointeur de fonction int func().
J'ai résolu cette erreur et quelques unes qui sont apparus après :)
Mais il en reste encore, forcément!
Une dizaine de ce type là et des erreurs LNK2019. Encore une fois je sèche... :cry:Code:transfer.obj : error LNK2001: symbole externe non résolu __imp__ExFreePoolWithTag
Bonjour,
Pour un "symbole externe non résolu", il te manque encore un fichier de bibliotheque, ou un fichier d'implémentation du dit symbole.
Je plussoie leternel et j'ajouterais uniquement le résultat d'une recherche google :
MSDN ExFreePoolWithTag
Citation:
Header : Wdm.h (include Wdm.h, Ntddk.h, or Ntifs.h)
Library : Contained in Ntoskrnl.lib
Ntoskrnl.lib est déjà dans le projet ("dépendance supplémentaires" toussa toussa) et j'avais déjà les #include "ntddk.h" pour chaque fichier. Dans le doute, j'ai essayé avec wdm.h mais ça ne change rien.
Donc apparemment il ne manque rien au projet... Je vais finir par connaitre par coeur les options de Visual à force :mrgreen:
En fouinant pour le "__imp__" je trouve ça : how-can-i-get-rid-of-the-imp-prefix-in-the-linker-in-vc
Et d'après pas mal d'autres liens, ça vient du fait que tu essayes de linker avec un .lib dédié à une DLL, alors que tu veux linker statiquement...
Ou quelque chose du genre dans ce genre là.
Y a-t-il des dllimport, dlopen ou autre dans ton code ?
Es-tu sûr aussi qu'il n'y a qu'une seule version de ntoskrnl.lib, et non pas, par exemple, une version statique et une version dynamique?
Je cherche, je cherche....Citation:
Envoyé par Metalman
8O Comment faire pour les différencier alors? Je les essaye un par un?Citation:
Envoyé par Médinoc
Apparemment, il n'y a qu'une seule version. Après analyse complète du disque dur, les différentes versions que je trouve sont celles qui fonctionnent avec d'autres versions de Windows.
J'ai toujours pas trouvé de dllimport ou de dlopen...
Il y a sans doute un #define NTKERNELAPI __declspec(dllimport) actif quelque part dans les headers.
Je ne connais pas assez le WDK pour savoir si c'est mauvais (si ntoskrnl.lib doit en fait être linké en statique) ou si c'est ton linkage qui n'arrive pas à lier à ntoskrnl.lib pour une raison ou une autre (/NODEFAULTLIB ?).