les .a sont les fichiers lib static pour gcc, les .lib pour msvc et clangCitation:
Envoyé par Artemus24
Version imprimable
les .a sont les fichiers lib static pour gcc, les .lib pour msvc et clangCitation:
Envoyé par Artemus24
@ Bousk : Un ".a" ne signifie pas nécessairement une bibliothèque statique. Cela dépend de l'outil que tu utilises.
Sous Windows, pour une DLL de nom test, on peut avoir plusieurs formats :
Je suis sous Msys64 (référencé Msys2) et j'utilise MinGW en 64bits.Code:
2
3
4
Si.Citation:
Un ".a" ne signifie pas nécessairement une bibliothèque statique.
Un fichier .a est une archive contenant différents fichiers .o au format ELF sous Linux, COFF/PE sous Windows.
Lors de la compilation en statique, tous les .o de cette archive contenant des symboles utilisés par ton code seront intégrés à l'executable.
Le format .a vient du monde Unix/Linux, Windows utilise .lib+dll pour les bibliothèques statiques.
Avec un compilateur natif Windows, ce sera .lib+dll, avec une toolchain tel que gcc/Mingw porté sous Linux, ça sera .a sauf si tu lui demande du .lib et qu'il est en mesure de le faire (je pense que ça doit être le cas pour gcc qui est capable de créer un exécutable PE pour Windows compilé depuis Linux : cross-compilation)
Un fichier .dll est normalement toujours accompagné d'un fichier .lib pour pouvoir linker la bibliothèque.
Si tu ne l'as pas, MinGW peut le reconstruire, il y a une commande pour ça. Avec MSVC, j'ai cru comprendre qu'on pouvait le faire indirectement.
sous Linux, c'est plus simple, tout est contenu dans le fichier .so (pour une lib dynamique).
Hello,
@Artemus24,
T'as eu ta réponse ? Perso, je trouve que les réponses de @Medinoc et @Guesset sont les réponses attendues (page 2 ou messages #11, #16 et #20).
ne pas oublier la technologie Component Object Model ou COM bref les dll Active X que l'on pouvait également créer avec Visual Basic.Citation:
Envoyé par Artemus24
D'ailleurs jusqu'au développement de .Net Microsoft en faisait un usage intensif dans ses produits comme la suite Office.
Cela permet une parfaite connectivité et interopérabilité entre les applications qui utilisent cette techno.
Je crois qu'avec Delphi il est possible aussi d'appeler une dll COM
@ Gerald3d : oups. Désolé de mettre trompé. J'ai corrigé en mettant le bon auteur, qui est Obsidian.
@Fred1599 : oui et non.
Je ne m'intéresse pas à la bibliothèque statique que je connais.
J'ai peu d'usage de la bibliothèque dynamique que je connais aussi. J'ai eu quelques réponses sur son usage.
Quand à la bibliothèque d'importation, je constate qu'elle n'est pas connnue du tout.
Non, je n'ai pas eu la réponse attendue concernant la bibliothèque d'importation.
Je rappelle que je cherche comme réponse son usage et non comment elle fonctionne.
J'utilise déjà ces trois biliothèques dans mon environnement.
C'est un peu le bordel, et j'aimerai ne pas me tromper dans la conformité de son usage.
J'ai une nette préférence pour la bibliothèque d'importation que je trouve plus souple à l'usage que la bibliothèque dynamique.
Et surtout cela m'évite de redéfinir plusieurs fois les mêmes fonctions.
En résumé, je pense que la bibliothèque dynamique est utilisé dans l'environnement Windows pour justement faire des écrans.
Voire aussi pour modifier ou compléter l'OS Windows sur des aspects systèmes que je ne connais pas.
Quand à la bibliothèque d'importation, je trouve très peu de trace sous Windows.
Je ne parle pas ici de Linux (dans mon cas Debian), car mon sujet s'intéresse bien à l'OS Windows.
J'aimerai comprendre si la bibliothèque d'importation supplante la bibliothèque dynamique comme étant une évolution pour simplifier sa lourdeur.
Pour quelle usage la bibliothèque d'importation à été conçue ?
Je développe en 'C/C++' sous Windows 10 Pro.
Anciennement (en 2010), j'utilisais 'Dev-C++', puis ensuite "MinGW' (en 2017) et maintenant (2026) "Msys2" (Msys64).
L'environnement "MinGW" que j'utilise maintenant, est celui inclue dans "Msys2", en 64 bits bien sûr.
Je ne connais pas les environnements suivants :
:fleche: Visual Studio puisque j'utilise Msys6 (Msys64 contenant MinGW 64 bits).
:fleche: outils MSVC
:fleche: visual basic
:fleche: active X
Pour les écrans Windows, je développe encore en Win32 à partir du livre de Charles Petzold, "1.Programming Windows, Fifth Edition" (1999).
Sinon, j'ai plusieurs livres sur le 'C', le 'C++' ainsi que sur UNIX. Ils sont tous anciens.
En fait, je fais une mise à niveau de mes anciens développements, entre autre passage au 64 bits.
Bah si en fait, tout a était dit.
Ce que tu appelles une bibliothèque d'importation n'est rien de plus qu'une bibliothèque statique qui va faire les LoadLibrary et compagnies de la bibliothèque dynamique. Ce fichier existe parce les conventions d'appel de mingw ne sont pas les mêmes que celle de msvc et c'était probablement plus simple de l'implémenter ainsi plutôt que consommer directement le .dll. Si le fichier est manquant, mingw peut le créer depuis la bibliothèque dynamique.
Et comme le dit @Medinoc, on charge manuellement une bibliothèque lorsque qu'on ne connaît pas à l'avance celle qu'on veut charger. Principalement pour les plugins, mais aussi lorsqu'on veut choisir un backend et qu'il y en a plusieurs de supporter. Souvent le cas pour tout ce qui est bibliothèque graphique avec mesa, opengl, etc. Ou si on veut supporter plusieurs versions d'une bibliothèque avec des fonctions qui peuvent exister ou non selon les versions. Tous ces cas nécessitent un chargement manuel pour s'adapter à l'environnement et que les bibliothèques ne sont pas fournies avec le programme.
Quand utiliser une "bibliothèque d'importation" ? Quand cette souplesse de chargement n'est pas nécessaire, tout simplement. Et par rapport à une statique: quand on ne fournit pas la bibliothèque dynamique, ou qu'on veut pouvoir mettre à jour une partie du programme sans tout mettre à jour l'ensemble ou simplement parce qu'on n'a pas la bibliothèque statique sous la main.
En fait dynamique et shared font référence à la même chose. C'est aussi le nom de l'option pour en produire sur GCC et certains systèmes de build utilisent shared plutôt que dynamique. C'est même le plus fréquent: xmake, cmake et meson pour ceux que je connais.Citation:
Envoyé par foetus
Je pense que ce nom vient à l'origine du fait qu'une bibliothèque dynamique est, au niveau système, partagée entre tous les process qui l'utilise. Les parties code et data ne sont chargés qu'une fois.
Voici un commentaire de WINDOWS à propos des DLL :
Donc une DLL c'est tout sauf "lourd" !!!Citation:
DLLs provide a way to modularize applications so that functionality can be updated and reused more easilly.
They also help reduce memory overhead when several applications use the same functionality at the same time, because although each application gets its own copy of the data, they can share the code.
A un détail près ... et voici l'exemple :
Il y a pas mal d'années (WIN 98) CBUILDER permettait de développer des exe peu encombrants car en arrière plan il y avait une myriade de DLLs.
Mais le problème survenait quand on changeait d'ordinateur non équipé de CBUILDER. Et plouf : il manquait des DLLs !
Donc CBUILDER proposait de compiler des "auto-suffisants", autrement dit d'intégrer dans l'exécutable les parties de code utiles depuis les DLLs.
Ok ! Mais le problème est que le poids de l'exe n'était plus le même : beaucoup plus grand !!!
Tout ça ... avait un coût en terme de stockage sur le disque dur !
Bien sûr, à l'heure actuelle, on dispose de capacités de stockage qui nous permettent de stocker toutes nos erreurs et le reste aussi !
salut Active X n'est pas un environnement de développement c'est une technologie.Citation:
Envoyé par Artemus24
Ça dépend du point de vue. C'est certain qu'au niveau stockage disque, si plusieurs applications l'utilisent, on y gagne. Mais rien n'est moins sûr au niveau mémoire.Citation:
Envoyé par henderson
Il faut savoir qu'une bibliothèque dynamique est une barrière d'optimisation: le compilateur ne pouvant pas savoir ce que fait la dll, il ne peut pas inliner le code, ni optimiser les appels et les retours puisqu'il n'a aucune connaissance du code derrière. Une fonction qui fait simplement le retour d'un membre d'une structure va être très coûteuse: sauvegarde la pile, appel de fonction, dépilement. Si la bibliothèque ne fait pas grand, ces instructions prennent à la fin beaucoup de place pour peu de code. Les .o et les bibliothèques statiques n'ont pas ce problème si on les compile avec LTO (Link Time Optimization), puisque le compilateur peut optimiser tout ça pendant la construction de l’exécutable.
Un autre point important concernant les bibliothèques dynamiques concerne le cycle de vie des objets créées. Si on veut être libre sur l'implémentation, comme ajouter ou supprimer des membres d'une structure sans devoir recompiler les programmes qui utilisent la bibliothèque, il faut que l'appelant n'ait pas connaissance du layout mémoire des classes / structures. Ce qui veut dire fournir un pointeur opaque (on déclare un type sans jamais le décrire, comme std::FILE) et exposer des fonctions de construction et de destruction. Fonction qui vont allouer dynamiquement de la mémoire, perdre en localité et ajouter un overhead sur le temps exécution et la mémoire. L'appelant doit en plus gérer la duré de vie en appelant les fonctions de destruction. Cela est bien plus lourd que des objets alloués sur la pile et libérés automatiquement par le compilateur.
Tout ça pour dire que l'utilisation de dll à un coût caché ou exposé dans les interfaces et que dans des cas extrêmes, utiliser une bibliothèque dynamique donne un exécutable plus gros qu'utiliser l'équivalent statique (sans compter le poids de la dll elle-même).
C'est un compilateur qui génère la dll, donc son code interne peut être optimisé, inliné. On ne pourra effectivement pas le faire sur une dll qui ne nous appartient pas, mais si son développeur a fait correctement le travail .. Et effectivement du code externe ne sera pas inlinable. Ca peut être un inconvénient.Citation:
le compilateur ne pouvant pas savoir ce que fait la dll, il ne peut pas inliner le code, ni optimiser les appels et les retours puisqu'il n'a aucune connaissance du code derrière.
Il est à noter qu'une bibliothèque peut être mise à disposition sans son code source avec la doc de son ABI.
L'usage d'une bibliothèque partagée a des avantages et des inconvénients.
Avantages :
- code non dupliqué ni sur disque, ni en RAM pour usage par plusieurs applications, ou plusieurs instances d'une même application.
- en cas de correction de code embarqué dans une bibliothèque dynamique, sa correction n'est pas à répercuter dans toutes les applis qui l'exploitent, elles ne devront pas être recompilés.
Inconvénient :
En cas de mise à jour majeure d'une bibliothèque, modifiant son ABI, la cohabitation de plusieurs versions de bibliothèques peut être compliqué
Liste probablement non exhaustive.
Bonjour Christophe,
Le code de la DLL peut effectivement être inline au sein de celle-ci, mais cette caractéristique n'est pas exportable. Inline consiste à remplacer les appels d'une fonction par le déploiement de son code source en lieu et place. Or ce dernier n'est pas accessible au compilateur de l'appelant (sinon ce serait une liaison statique). Par ailleurs l'application utilisatrice n'est pas nécessairement écrite dans le même langage, il suffit que son code source intègre l'équivalent du .h de la DLL pour pouvoir l'utiliser.Citation:
Envoyé par Christophe
Salut