Différence entre les bibliothèques statiques et partagées?

Quelle est la différence entre les bibliothèques statiques et partagées?

J'utilise Eclipse et il existe plusieurs types de projets, y compris les bibliothèques statiques et les bibliothèques partagées? L'un a-t-il un avantage sur l'autre?

Les bibliothèques partagées sont des fichiers .so (ou Windows .dll ou OS X .dylib). Tout le code relatif à la bibliothèque est dans ce fichier, et il est référencé par les programmes l'utilisant au moment de l'exécution. Un programme utilisant une bibliothèque partagée fait uniquement référence au code qu'il utilise dans la bibliothèque partagée.

Les bibliothèques statiques sont des fichiers .a (ou Windows .lib). Tout le code relatif à la bibliothèque est dans ce fichier, et il est directement lié au programme au moment de la compilation. Un programme utilisant une bibliothèque statique prend des copies du code qu'il utilise à partir de la bibliothèque statique et l'intègre au programme. [Windows a également des fichiers .lib qui sont utilisés pour référencer les fichiers .dll, mais ils agissent de la même manière que le premier].

Il y a des avantages et des inconvénients dans chaque méthode:

• Les bibliothèques partagées réduisent la quantité de code qui est dupliqué dans chaque programme qui utilise la bibliothèque, en gardant les binaires petits. Il vous permet également de remplacer l'objet partagé par un qui est fonctionnellement équivalent, mais peut avoir des avantages de performances supplémentaires sans avoir besoin de recompiler le programme qui l'utilise. Les bibliothèques partagées auront cependant un petit coût supplémentaire pour l'exécution des fonctions ainsi qu'un coût de chargement au moment de l'exécution car tous les symboles de la bibliothèque doivent être connectés aux choses qu'ils utilisent. De plus, les bibliothèques partagées peuvent être chargées dans une application au moment de l'exécution, qui est le mécanisme général de mise en œuvre des systèmes de plug-in binaires.

• Les bibliothèques statiques augmentent la taille globale du binaire, mais cela signifie que vous n'avez pas besoin de transporter une copie de la bibliothèque utilisée. Comme le code est connecté au moment de la compilation, il n'y a aucun coût de chargement supplémentaire lors de l'exécution. Le code est simplement là.

Personnellement, je préfère les bibliothèques partagées, mais utilisez des bibliothèques statiques lorsque vous devez vous assurer que le binaire n'a pas de nombreuses dépendances externes qui peuvent être difficiles à satisfaire, telles que des versions spécifiques de la bibliothèque standard C ++ ou des versions spécifiques de la bibliothèque Boost C ++.

Une bibliothèque statique est comme une librairie, et une bibliothèque partagée est comme ... une bibliothèque. Avec le premier, vous obtenez votre propre exemplaire du livre / de la fonction à rapporter à la maison; avec ce dernier, vous et tous les autres allez à la bibliothèque pour utiliser le même livre / la même fonction. Donc, quiconque souhaite utiliser la bibliothèque (partagée) doit savoir où elle se trouve, car il faut "aller chercher" le livre / la fonction. Avec une bibliothèque statique, le livre / la fonction est à vous, et vous le gardez dans votre maison / programme, et une fois que vous l'avez, peu importe où ou quand vous l'avez obtenu.

Simplifié:

• Liaison statique: un grand exécutable
• Liaison dynamique: un petit exécutable plus un ou plusieurs fichiers de bibliothèque (fichiers .dll sur Windows, .so sur Linux ou .dylib sur macOS)

Pour une bibliothèque statique, le code est extrait de la bibliothèque par l'éditeur de liens et utilisé pour construire l'exécutable final au moment où vous compilez / construisez votre application. L'exécutable final n'a pas de dépendances sur la bibliothèque au moment de l'exécution

Pour une bibliothèque partagée, le compilateur / éditeur de liens vérifie que les noms avec lesquels vous liez existent dans la bibliothèque lors de la génération de l'application, mais ne déplace pas leur code dans l'application. Au moment de l'exécution, la bibliothèque partagée doit être disponible.

Le langage de programmation C lui-même n'a aucun concept de bibliothèques statiques ou partagées - ils sont complètement une fonctionnalité d'implémentation.

Personnellement, je préfère de loin utiliser des bibliothèques statiques, car cela simplifie la distribution de logiciels. Cependant, c'est une opinion sur laquelle beaucoup de sang (figuratif) a été versé dans le passé.

Les bibliothèques statiques sont compilées dans le cadre d'une application, contrairement aux bibliothèques partagées. Lorsque vous distribuez une application qui dépend de bibliothèques partagées, les bibliothèques, par exemple. les DLL sur MS Windows doivent être installées.

L'avantage des bibliothèques statiques est qu'aucune dépendance n'est requise pour l'utilisateur exécutant l'application - par exemple, il n'a pas à mettre à jour sa DLL. L'inconvénient est que votre application est plus grande car vous la livrez avec toutes les bibliothèques dont elle a besoin.

En plus de conduire à des applications plus petites, les bibliothèques partagées offrent à l'utilisateur la possibilité d'utiliser leur propre version, peut-être meilleure, des bibliothèques plutôt que de s'appuyer sur celle qui fait partie de l'application.

L'avantage le plus important des bibliothèques partagées est qu'il n'y a qu'une seule copie de code chargée en mémoire, quel que soit le nombre de processus utilisant la bibliothèque. Pour les bibliothèques statiques, chaque processus obtient sa propre copie du code. Cela peut entraîner un gaspillage de mémoire important.

OTOH, un avantage des bibliothèques statiques est que tout est intégré à votre application. Vous n'avez donc pas à vous soucier que le client aura la bonne bibliothèque (et la bonne version) disponible sur son système.

En plus de toutes les autres réponses, une chose non encore mentionnée est le découplage:

Permettez-moi de parler d'un code de production du monde réel, que j'ai traité:

Un très gros logiciel, composé de> 300 projets (avec Visual Studio), principalement construit en tant que bibliothèque statique et enfin tous lié ensemble dans un énorme exécutable, vous vous retrouvez avec les problèmes suivants:

-Le temps de liaison est extrêmement long. Vous pourriez vous retrouver avec plus de 15 minutes de lien, disons 10 secondes de temps de compilation - Certains outils sont à genoux avec un si gros exécutable, comme les outils de vérification de la mémoire qui doivent instrumenter le code. Vous pourriez tomber dans des limites qui avaient été vues comme des imbéciles.

Le découplage de votre logiciel est plus problématique: sur cet exemple réel, les fichiers d'en-tête de chaque projet étaient accessibles à partir de n'importe quel autre projet. En conséquence, il était extrêmement facile pour un développeur d'ajouter des dépendances; il s'agissait simplement d'inclure l'en-tête, car à la fin, le lien trouvera toutes les symboles. Il finit par d'horribles dépendances cyclistes et un désordre complet.

Avec la bibliothèque partagée, c'est un peu de travail supplémentaire car le développeur doit modifier le système de construction du projet pour ajouter la bibliothèque dépendante. J'ai observé que le code de bibliothèque partagée tend à offrir une API de code plus propre.

-------------------------------------------------------------------------
|  +-  |    Shared(dynamic)       |   Static Library (Linkages)         |
-------------------------------------------------------------------------
|Pros: | less memory use          |   an executable, using own libraries|
|      |                          |     ,coming with the program,       |
|      |                          |   doesn't need to worry about its   |
|      |                          |   compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of       |   bigger memory uses                |
|      | libraries may be altered |                                     |
|      | subject to OS  and its   |                                     |
|      | version, which may affect|                                     |
|      | the compilebility and    |                                     |
|      | runnability of the code  |                                     |
-------------------------------------------------------------------------