Liaison: fichiers .a, .lib et .def
Je crée une DLL à partir de Assembly sur Windows en utilisant les binutils GNU.
Je sais que la dll peut être chargée lorsque l'exécutable est chargé ou au moment de l'exécution (en utilisant l'appel api LoadLibrary).
Pour le chargement au moment du chargement, il me semble que je n'ai besoin que du fichier dll: aucun fichier .a, .lib ou .def n'est nécessaire. Je me suis demandé ce que ces formats de fichiers représentent et à quoi servent-ils.
Ce que je sais et quelques questions spécifiques:
.a est l'extension généralement utilisée pour la bibliothèque statique sous Unix. Les fichiers .a sont générés avec l'option - out-implib de GNU ld. On dit que c'est une "bibliothèque d'importation", c'est juste. La question est puis "À quoi sert une bibliothèque d'importation pour moi si je n'en ai pas besoin lors de la liaison?"
.lib est l'extension utilisée pour la bibliothèque statique sous Windows et, selon wikipedia, est également utilisée comme "bibliothèque d'importation" sous Windows, donc je soupçonne fortement qu'il ne s'agit que d'un autre nom pour ce que les binutils appellent les fichiers .a. Vrai faux ?
Toutes les pages, je peux trouver des points que les fichiers .def répertorient le symbole exporté de la DLL. N'est-ce pas quelque peu semblable à ce qu'une "bibliothèque d'importation" est censée faire?
En outre, j'ai lu ici que l'utilisation de fichiers .def est une alternative à la spécification manuelle des exportations dans le fichier source (ce que j'ai fait). Mais je me souviens aussi d'avoir lu (ne peut pas trouver de référence). Le fichier .def fournit un index ( ordinal ) dans les symboles exportés, permettant un chargement plus rapide au moment de l'exécution. Est-ce vrai ?
Les bibliothèques statiques sous Linux ont le .a extension de fichier. Les bibliothèques statiques sous Windows ont le .lib extension de fichier. Les bibliothèques dynamiques sous Windows ont le .dll extension; pour établir un lien avec une DLL, une bibliothèque d'importation est requise. La bibliothèque d'importation est une bibliothèque statique. Il contient le code requis pour charger la DLL. Vous utilisez maintenant GCC (pas cl.exe) pour compiler sous Windows. GCC a une autre convention d'extension de fichier pour les bibliothèques d'importation, elle "devrait être appelée * .dll.a ou * .a", comme expliqué dans le doc pour le --out-implib dont vous avez parlé.
Importer des bibliothèques (.lib avec MSVC ou .dll.a avec GCC) sont des bibliothèques statiques : elles contiennent le code pour charger la DLL. J'ai eu la même question l'autre jour.
A DLL peut avoir des fonctions qui sont exportées et des fonctions qui ne sont pas exportées. Une bibliothèque d'importation doit savoir quelles fonctions sont exportées et lesquelles ne le sont pas. L'un des moyens de le dire est un DEF fichier.
Lors de la création de la DLL, l'éditeur de liens utilise le fichier .def pour créer un fichier d'exportation (.exp) et un fichier de bibliothèque d'importation (.lib). L'éditeur de liens utilise ensuite le fichier d'exportation pour créer le fichier DLL. Exécutables qui lient implicitement au lien DLL vers la bibliothèque d'importation lors de leur construction. - MSDN: Exportation à partir d'un DLL à l'aide de fichiers DEF
Voir aussi MSDN: Exportation de fonctions à partir d'un DLL par Ordinal plutôt que par nom , ensemble qui devrait répondre à votre dernière question sur l'exportation par index ou numéro ordinale.