Les bibliothèques statiques C sont-elles mal vues? [fermé]

Il y a 2 arguments pour avoir des bibliothèques partagées:

1. Il aide à réduire l'espace disque.
2. Lorsqu'une bibliothèque partagée est mise à jour, tous les binaires qui en dépendent reçoivent la mise à jour.

Il y a principalement un inconvénient pour les bibliothèques partagées:

• Ils (peuvent) introduire l'enfer de la dépendance.

Sur les ordinateurs de bureau, le 1er avantage ne tient plus vraiment. Le gaspillage d'espace disque n'est plus vraiment un problème de nos jours.

Avoir des binaires statiques nous permettrait d'obtenir de bien meilleurs gestionnaires de paquets - je veux dire, l'enfer de la dépendance serait une chose du passé. Ajouter un programme serait simplement ajouter un binaire; éventuellement un dossier pour le laisser gérer ses fichiers. Supprimer un programme reviendrait simplement à supprimer ce fichier. Dépendances? Disparu.

Le deuxième avantage est toujours valable, mais je pense que l'avantage des binaires statiques sur les ordinateurs de bureau l'emporte. Je veux dire, même de nouvelles langues comme Go compilent tous leurs binaires malgré les avantages des bibliothèques partagées, à cause de la commodité.

Étant donné que l'un des principaux avantages des bibliothèques partagées n'est plus un problème, les bibliothèques statiques C sont-elles toujours mal vues? Si oui, pourquoi?

La prémisse de votre question est erronée. Ce qui est mal vu, c'est de s'en tenir aux doctrinaires et aux absolus sans aucune compréhension de la base derrière eux (Cargo Cult Programming?).

La réponse SO liée est une étude intéressante dans ce même sujet - la question était de savoir pourquoi une compilation avec l'option -static ne fonctionnait pas, la réponse à laquelle vous étiez lié n'était rien de plus qu'une diatribe de ne pas utiliser de liaison statique. Si ne discute pas pourquoi son mauvais, et exige l'OP utilise la liaison dynamique. C'est malheureux, il est marqué comme la bonne réponse (la réponse suivante a deux fois plus de votes et est la bonne réponse à la question du PO) car bien que la bonne réponse soit là, elle est profondément cachée parmi une opinion dogmatique.

La vraie question est de savoir quels sont les avantages et les inconvénients de la liaison statique vs dynamique et quand serait-on préféré à l'autre.

Du point de vue du développeur, la liaison dynamique peut souvent accélérer considérablement votre boucle de compilation / lien / test.

Du point de vue de la gestion des packages, prenez par exemple libGL. J'ai environ une douzaine d'implémentations différentes disponibles dans mon gestionnaire de packages, certaines génériques et certaines ciblant des cartes graphiques spécifiques. S'il n'était pas lié dynamiquement, il devrait y avoir une douzaine de versions de chaque programme qui se relient à libGL, ou bien vous devriez concevoir une couche supplémentaire d'abstraction qui n'est pas aussi efficace qu'un appel de fonction.

Pensez à un problème de sécurité dans une bibliothèque populaire comme Qt. Avec la liaison dynamique, je peux simplement mettre à jour ce package, au lieu d'avoir à identifier, recompiler et déployer chaque package qui relie dans Qt.

La liaison statique peut présenter des avantages dans les applications de sources fermées déployées de manière indépendante, mais dans la gestion des packages open source, cela fait plus mal que cela n'aide.

Les bibliothèques partagées sont fortement préférées par les responsables de la distribution Linux pour essentiellement votre raison n ° 2. Il est vraiment important pour eux que, par exemple, lorsque quelqu'un trouve un bogue de sécurité dans zlib , il n'ait pas à recompiler chacun des programmes qui utilisent zlib --- non seulement cela leur coûterait plus de cycles CPU pour faire le lors de la recompilation, tous ceux qui utilisent la distribution devraient alors télécharger à nouveau tous ces programmes. En attendant, au sein de l'ensemble des packages fournis par une distribution, l'enfer de dépendance n'est pas un problème, car tout est testé pour fonctionner avec cet ensemble de bibliothèques.

Si vous créez un logiciel tiers qui a besoin de bibliothèques qui ne sont pas dans votre distribution, la liaison statique de ces bibliothèques peut être moins compliquée que l'alternative, et c'est très bien.

L'autre chose importante à savoir est que GNU libcet GCC ont libstdc++tous deux des composants qui ne fonctionnent pas de manière fiable si la bibliothèque est liée statiquement. Le problème le plus courant est avec dlopen, car le module avec lequel vous chargez dlopenest lui-même lié dynamiquementlibc.so.6 . Cela signifie donc que vous avez maintenant deux copies de la bibliothèque C dans votre espace d'adressage, et l'hilarité s'ensuit quand ils ne s'entendent pas sur la copie de la mallocstructure de données interne (par exemple) qui fait autorité. Cela empire: tout un tas de fonctions qui ne semblent avoir rien à voir avec dlopen, comme gethostbynameet iconv, utiliserdlopenen interne (pour que leur comportement soit configurable à l'exécution). Heureusement, l'ABI pour libc et libstdc ++ est très stable, il est donc peu probable que vous rencontriez des problèmes pour les lier dynamiquement.

Je suis d'accord avec le dernier point de Mattnz: cette question est une question chargée. Il suppose que la liaison statique est mauvaise. Je peux penser à deux raisons pour lesquelles ce n'est pas le cas:

• La liaison statique est sûre: si une bibliothèque partagée est mise à jour de sorte qu'une application utilise la nouvelle (peut-être que la nouvelle écrase l'ancienne ou que l'ancienne est supprimée), cela peut présenter un risque que la nouvelle version casse l'application. Il s'agit d'un changement de code qui sort du cadre d'une mise à jour officielle de l'application. Il n'a peut-être pas été testé. La liaison statique évite cela en ne partageant pas les bibliothèques en externe. Je considère que c'est un inconvénient pour les bibliothèques partagées en raison de ce risque. Que se passe-t-il si une nouvelle version d'une bibliothèque partagée introduit un nouveau bogue qui casse certaines applications plus anciennes?

• La liaison statique garantit qu'une application est plus autonome. Bien que les bibliothèques partagées puissent être colocalisées avec l'exécutable principal, elles sont souvent déposées dans des emplacements partagés. Les applications liées statiquement sont plus faciles à garantir "portables" dans le sens de "ne nécessiter aucune modification des fichiers, répertoires ou paramètres appartenant au système d'exploitation" (pensez au répertoire Windows, au registre, / etc).

Les bibliothèques statiques et dynamiques ont chacune leurs propres utilisations. En examinant une seule application, nous obtenons une idée différente de ce qui est nécessaire et de ce qui ne l'est pas.

La liaison statique simplifie considérablement le déploiement d'applications. Ne pas avoir à détecter et gérer différentes versions. Il suffit de cuire et de déployer.

L'avantage évident des bibliothèques dynamiques est la possibilité d'appliquer des mises à jour de manière indépendante.

C'est l'une des raisons pour lesquelles je déteste maven et d'autres constructeurs de projets de liaison dynamique similaires pour java. Ils s'attendent à ce qu'une version de bibliothèque unique soit disponible pour une URL donnée pour toujours et à jamais. Ne pas comprendre le problème qui se produit en 10 ans lorsque personne ne peut compiler l'application car toutes les sources et tous les bocaux ont disparu.