2010-01-19 20 views
13

Je vais commencer un nouveau projet C++ qui reposera sur une série de bibliothèques, y compris une partie des bibliothèques Boost, le log4cxx ou la bibliothèque de journalisation google - et que le projet évolue autres aussi (que je ne peux pas encore anticiper).Application C++ - dois-je utiliser une liaison statique ou dynamique pour les bibliothèques?

Il devra fonctionner sur les systèmes 32 et 64 bits, plus probablement dans un environnement Linux très diversifié où je ne vous attendez pas à avoir toutes les bibliothèques requises disponibles ni privilèges su.

Ma question est, dois-je construire mon application en reliant dynamiquement ou statiquement à toutes ces bibliothèques?

Notes:

(1) Je suis conscient de la liaison statique peut être une douleur au cours du développement (compilation plus temps, la compilation croisée pour les 32 et 64 bits, en descendant des chaînes de dépendance pour inclure toutes les bibliothèques, etc.), mais c'est beaucoup plus facile pendant le test - il suffit de déplacer le fichier et de courir. D'autre part, les liens de liaison dynamiques sont plus faciles pendant la phase de développement - temps de compilation courts (ne savent pas vraiment comment gérer la liaison dynamique aux bibliothèques 64 bits de mon environnement de développement 32 bits), chaînes de dépendance. De plus, le déploiement de nouvelles versions peut être moche - en particulier lorsque de nouvelles bibliothèques sont requises (voir la condition ci-dessus de ne pas avoir de droits su sur les machines ciblées, ni ces bibliothèques disponibles).

(3) J'ai lu des questions connexes concernant ce sujet, mais ne pouvait pas vraiment savoir quelle approche convient le mieux à mon scénario.

Conclusions:

  1. Merci à tous pour vos commentaires!
  2. Je vais probablement aller avec la liaison statique parce que:
    • déploiement plus facile
    • performances et des résultats plus Prévisible cohérents au cours de perf. les tests (voir cet article: http://www.inf.usi.ch/faculty/hauswirth/publications/CU-CS-1042-08.pdf)
    • Comme il est indiqué, la taille et la durée de la compilation de l'électricité statique vs dynamique ne semble pas être une telle différence énorme
    • Cycles de test plus faciles et plus rapides
    • Je peux garder tous les dev. cycle sur mon dev. Machine

Répondre

11

La liaison statique a une mauvaise réputation. Nous avons d'énormes disques durs ces jours-ci, et extraordinairement gros tuyaux. Beaucoup de vieux arguments en faveur de la liaison dynamique sont beaucoup moins importants maintenant. De plus, il y a une bonne raison de préférer les liens statiques sous Linux: la pléthore de configurations de plates-formes rend presque impossible de garantir que votre exécutable fonctionnera même pour une petite fraction d'entre eux sans lien statique. Je soupçonne que ce ne sera pas une opinion populaire. Bien. Mais j'ai 11 ans d'expérience dans le déploiement d'applications sur Linux, et jusqu'à ce que quelque chose comme LSB décolle vraiment et étende vraiment sa portée, Linux continuera à être beaucoup plus difficile à déployer des applications. Jusque-là, reliez votre application de manière statique si vous devez utiliser un large éventail de plates-formes.

+3

Il le rend également plus robuste après l'installation. Si l'utilisateur installe quelque chose qui change les bibliothèques dynamiques, votre programme ne sera pas affecté. – Jay

+0

Un problème encore très valable avec la liaison statique (et aussi avec les bibliothèques groupées) est que les mises à jour de sécurité nécessaires sont souvent négligées. – wich

+0

Je n'ai pas vu d'améliorations notables dans la vitesse avec la liaison dynamique sur Linux. aller avec statique - c'est plus facile et l'empreinte de la mémoire pour votre application sera plus petite à moins qu'un autre programme ne fonctionne en même temps avec exactement la même dépendance (les bibliothèques dynamiques doivent être chargées dans leur intégralité en mémoire, même si vous seulement utilisez 1 fonction). –

4

Je probablement utiliser la liaison dynamique au cours (la plupart) le développement, puis passer à la liaison statique pour les phases finales du développement et de (tous) le déploiement. Heureusement, il n'y a pas besoin de tests supplémentaires lorsque l'on passe de la liaison dynamique à la liaison statique des bibliothèques.

1

Le mieux est de laisser cela à l'emballeur et de fournir les deux options du configure/make scripts. Habituellement, la liaison dynamique aurait la préférence depuis lors, il serait facile de mettre à niveau les bibliothèques si nécessaire, c'est-à-dire lorsque des failles de sécurité, etc., sont découvertes. Notez que si vous n'avez pas les privilèges root pour installer les bibliothèques dans les répertoires système, vous pouvez compiler le programme de manière à chercher d'abord les bibliothèques dynamiques nécessaires, ceci en définissant la directive runpath dans les binaires ELF .Vous pouvez spécifier un tel répertoire avec l'option -rpath de l'éditeur de liens ld.

+0

Ou laissez la personne qui exécute le programme indiquer qu'elle doit rechercher dans des répertoires supplémentaires en utilisant la variable d'environnement LD_LIBRARY_PATH. – jamessan

2

Ceci est un autre vote pour la liaison statique. Je n'ai pas remarqué de temps de liaison significativement plus longs pour l'application. L'application en question est une application de console de ligne ~ 50K, avec plusieurs bibliothèques qui sont compilées pour un tas de machines hors de l'ordinaire, la plupart du temps des supercalculateurs avec 100-10 000 cœurs. Avec la liaison statique, vous savez exactement quelles bibliothèques vous allez utiliser, vous pouvez facilement en tester de nouvelles versions.

En général, c'est ainsi que la plupart des applications Mac sont construites. C'est ce qui permet à l'installation de copier simplement un répertoire sur le système.