Linux liaison statique est mort?

En fait, -statique gcc drapeau sur Linux ne fonctionne pas aujourd'hui. Permettez-moi de citer de la GNU libc FAQ:

2.22. Même lié statiquement les programmes ont besoin de certaines bibliothèques partagées
ce qui n'est pas acceptable pour moi. Ce
puis-je faire?

{AJ} NSS (pour plus de détails tapez simplement `info
libc "Name Service Switch"') ne sont pas
travail correctement sans partagée
des bibliothèques. NSS permet l'utilisation de différents
services (par exemple, NIS, fichiers, db, hésiode)
en changeant juste une configuration
le fichier/etc/nsswitch.conf) sans
re-lier tous les programmes. La seule
l'inconvénient est que maintenant statique
les bibliothèques ont besoin de l'accès partagé
des bibliothèques. C'est géré
de manière transparente par la bibliothèque C de GNU.

Une solution est de configurer la glibc avec
--enable-static-nss. Dans ce cas, vous pouvez créer un binaire statique qui
utiliser uniquement les services dns et les fichiers
(changer /etc/nsswitch.conf pour cela).
Vous avez besoin de relier explicitement contre
l'ensemble de ces services. Par exemple:

 gcc -static test-netdb.c -o test-netdb \
   -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group

Le problème avec cette approche est
que vous avez obtenu pour chaque lien statique
programme qui utilise NSS routines avec
toutes ces bibliothèques.

{UD} En fait, on ne peut pas en dire plus, qu'une libc compilé avec cette option
est l'aide de NSS. Il n'y a pas d'interrupteur
plus. Par conséquent, il est très
recommandé pas à utiliser
--enable-static-nss car cela rend le comportement des programmes sur l'
système incohérent.

Concernant ce fait est-il raisonnable de façon à créer un plein fonctionnement de l'accumulation d'électricité statique sur Linux ou sur la liaison statique est complètement morte sur Linux? Je veux dire l'accumulation d'électricité statique qui:

  • Se comporte exactement de la même manière que
    dynamique de construire n' (statique-nss avec
    comportement incohérent est le mal!);
  • Travaux sur les variations de la glibc de l'environnement et de versions de Linux;
  • N'a pas d'autre remplacement de la bibliothèque C convenir à votre but? (alimentation / uclibc / etc) ?
  • Utilisent-ils NSS? Le plus probable, le comportement vais être incompatibles, car je doute que ces bibliothèques prendre en compte NSS.
  • Ne vous utilisez toutes les fonctions qui finalement se termine par l'appel à nss (par exemple gethostname/getpwname/getgroups/etc.) ?
  • Assurez -)) C'est une application client/serveur.
  • Est-ce toujours le cas ou les choses ont changé depuis 2010?
  • découvrez static linux

InformationsquelleAutor Shcheklein | 2010-08-07
  1. 28

    Concernant ce fait est-il raisonnable de façon à créer un plein fonctionnement de l'accumulation d'électricité statique sur Linux ou sur la liaison statique est complètement morte sur Linux?

    Je ne sais pas où trouver les références historiques, mais oui, la liaison statique est morts sur des systèmes GNU. (Je crois qu'il est mort lors de la transition de libc4/libc5 de libc6/glibc 2.x.)

    La fonctionnalité a été jugé inutile à la lumière de:

    • Des failles de sécurité. L'Application qui a été lié statiquement ne prend même pas en charge les mises à niveau de la libc. Si l'application a été lié sur le système contenant une lib de vulnérabilité, alors il va se perpétuer au sein de l'exécutable lié statiquement.

    • Code de la météorisation. Si de nombreuses applications liées statiquement sont a couru sur le même système, les bibliothèques standard ne serait pas être réutilisés, car chaque application contient à l'intérieur de sa propre copie de tout. (Essayez du -sh /usr/lib pour comprendre l'étendue du problème.)

    Essayer de creuser la LKML et glibc mail les archives de la liste de 10-15 ans. Je suis assez sûr il y a longtemps j'ai vu quelque chose sur la LKML.

    • Malheureusement, ils ont omis de mentionner l'autre côté: statique liée binaires prendre 90% de temps en moins pour le démarrage et beaucoup moins sale page de surcharge que leur dynamique liée homologues. Ces jours-ci, la eglibc fourche de glibc a fait de la liaison statique au moins à mi-chemin-de nouveau possible, mais si vous voulez à réellement utiliser la liaison statique sans gigantesque binaires et les bugs/problèmes comme nss, vous avez probablement besoin d'utiliser un autre libc mise en œuvre.
    • vous avez écrit, "... mais si vous voulez à réellement utiliser la liaison statique sans gigantesque binaires et les bugs/problèmes comme nss, vous avez probablement besoin d'utiliser un autre libc mise en œuvre". Personne ne sait d'une mise en œuvre de la libc qui fournit statique accès aux ssn? Je voudrais statique accès à getgrgid_r() dans un environnement NIS. Théoriquement, quelqu'un peut mettre en œuvre grgetgid_r et d'autres routines utilisant statique de l'accès à la sous-jacentes NIS routines. Quelqu'un a fait cela?
    • Toutes les libcs avec la prise en charge NIS avait les routines de manière statique inclus - pas de NSS non-sens. NSS a été inventé beaucoup plus tard. uClibc n'utilise pas le chargement dynamique de modèle comme NSS, et je suis sûr à 99% qu'il prend en charge NIS.
    • Je pense que ma réponse est obsolète: j'ai lié statiquement un de taille moyenne d'applications avec pas de problèmes, que ce soit sur Ubuntu 14.04. Mais le raisonnement pourquoi la liaison statique est mauvais reste le même. À moins, bien sûr, l'un gravement besoins les bonus listés par R.. ci-dessus, et ils l'emportent sur les inconvénients.
    • Dynamicly bibliothèque de liens peut être allumé en même contrepartie en cas de modification du corps de la fonction contenant malisious code. Ne jamais se lier dynamiquement si vous ne faites pas confiance à la source (ne jamais faire confiance à la source ou vous êtes en difficulté). Sur une note côté, le CRC a été violée par les superordinateurs, il y a longtemps.
    • lié binaires prendre 90% de temps en moins pour le démarrage et beaucoup moins sale page de surcharge que leur dynamique liée homologues" - il serait bien de voir un prooflink pour ce sinistre.
    • J'ai un programme de test qui mesure le temps écoulé à partir juste avant execve la première ligne de main après l'auto-exec. Pour un banal programme avec pas de bibliothèques partagées à l'exception de la libc, la liaison statique prend environ 50% de temps en moins à l'auto-exec, et le temps est de l'ordre de quelques dizaines ou centaines de microsecondes en fonction de la vitesse de la machine. Jeter quelques shared libs et vous pouvez facilement le faire à 90% de moins. Vous êtes en comparant O(n) en temps O(1) temps donc, peu importe comment petit la par-lib coût que vous pouvez atteindre arbitrairement proche de 100%, mais dans la pratique, il ne prend que quelques.
    • Intéressant, je peux voir maintenant que Prelink rapporté des résultats similaires. Je suppose que les frais généraux provient essentiellement EU/PLT exécution de relocalisation de la transformation et de manière récursive à chasser les dépendances?
    • Même juste mmap surcharge est assez importante avec beaucoup de bibliothèques. Pour les petites bibliothèques mmap temps va dominer de toute façon, mais pour les grands (de l'esp. C++) des bibliothèques, à la relocalisation de temps, y compris la demande de pagination dans tous les data/EU de la page qui doit être patché, est le facteur dominant.
    • Avez-vous pensé à bloguer à ce sujet? Je suis sûr que beaucoup de gens aimeraient voir le détail des graphiques et des chiffres.

    InformationsquelleAutor Dummy00001
  2. 42

    Je pense que c'est très ennuyeux, et je pense qu'il est arrogant pour appeler une fonction "inutile" parce qu'il a des problèmes avec certains cas d'utilisation. Le plus gros problème avec la glibc approche est qu'il est difficile de codes chemins de bibliothèques (gconv ainsi que nss), et donc il se casse quand les gens essaient d'exécuter un binaire statique sur une distribution Linux différent de celui qu'il a été construit pour les.

    De toute façon, vous pouvez travailler autour de la gconv problème en définissant GCONV_PATH pour pointer vers l'emplacement approprié, cela m'a permis de prendre binaires construit sur Ubuntu et de les exécuter sur Red Hat.

    InformationsquelleAutor Ketil
  3. 20

    Liaison statique ne semble pas obtenir beaucoup d'amour dans le monde de Linux. Voici mon point de vue.

    Gens qui ne voient pas l'appel de la liaison statique généralement travailler dans le domaine de l'amande et de bas niveau du système d'exploitation. Beaucoup de *nix bibliothèque développeurs ont passé leur vie à traiter avec les inévitables problèmes d'essayer de lier d'une centaine de constante évolution des bibliothèques ensemble, une tâche qu'ils font chaque jour. Jetez un oeil à autotools si jamais vous voulez savoir les backflips ils sont à l'aise d'effectuer.

    Mais tout le monde ne doit pas être prévu de passer la plupart de leur temps sur cette. La liaison statique vous prendra un long chemin vers le tampon de la bibliothèque du taux de désabonnement. Le développeur peut mettre à niveau son logiciel de dépendances en fonction du logiciel de planification, plutôt que d'être forcé de le faire dès que de nouvelles versions de la bibliothèque apparaît. Ceci est important pour les utilisateurs d'applications avec des interfaces utilisateur complexes qui ont besoin de contrôler le flux de la de nombreux de niveau inférieur bibliothèques dont ils dépendent inévitablement. Et c'est pourquoi je serai toujours un fan de la liaison statique. Si vous pouvez lier statiquement cross-compilé portable code C et C++, vous avez assez bien fait, le monde est votre huître, comme vous pouvez vous en offrir plus rapidement des logiciels complexes à un large éventail de la mondiale sans cesse croissante des appareils.

    Il ya beaucoup à être en désaccord avec il y, à partir d'autres points de vue, et c'est agréable que les logiciels open source qui permet de les tous.

    • Il serait juste de mentionner les inconvénients de la liaison statique: immunité à la bibliothèque de mises à jour (et donc bug/vulnérabilité des correctifs), plus de temps de liaison et les plus grandes exécutable tailles.
    • Au contrere, vous n'avez toujours mises à jour des bibliothèques, juste au moment où vous en avez besoin, par exemple quand vous vous approchez d'une sortie et il est intéressant d'intégrer les derniers correctifs de sécurité - c'est moins de perte de temps. Essayez de ninja pour accélérer les temps de liaison. Il est assez rare situation où la taille du binaire questions beaucoup - peut-être dans les petits espaces, mais vous pouvez enlever votre OS de shared libs dans ce cas. Encore une fois, les cas d'utilisation varient, ymmv, tout ça.
    • "vous n'avez toujours mises à jour des bibliothèques, juste au moment où vous en avez besoin" - normalement, la personne qui a vraiment besoin de la mise à jour est à l'utilisateur de votre application qui peut à présent pas, il suffit de s'appuyer sur automatique des mises à jour de sécurité fournis par la distribution des responsables, mais doit suivre selon versions de la bibliothèque sont utilisés dans votre statiquement le binaire (ou compter sur vous pour relier le dit binaire contre fixe les bibliothèques, en temps opportun, de dupliquer le travail de distribution de l'équipe de sécurité).
    • "Essayez de ninja pour accélérer les temps de liaison" - je ne suis pas sûr de savoir comment Ninja peut augmenter la vitesse de mon éditeur de liens.
    • "Il est assez rare situation où la taille du binaire questions beaucoup" - pas une seule fois une nouvelle langue majeure liens tous de son exécutables, actuels et futurs, de manière statique, rendant la situation encore pire avec chaque nouveau paquet.
    • L'explosion de conteneurs docker montrer un grand intérêt dans la capture d'un ensemble statique de l'environnement, encore et encore, au détriment de la taille du disque. Mais encore une fois, comme je l'ai dit, cela dépend des cas, vous pouvez avoir affaire à un petit exécutable que vous avez à charger dans un busybox environnement ou autres joyeusetés. À ce point, nous sommes "en avançant sur internet". J'admets il y a des moments où les points que vous mentionnez sont valides.

    InformationsquelleAutor moodboom
  4. 13

    Juste parce que vous avez un lien dynamique vers le NSS service ne signifie pas que vous ne peut pas lier statiquement à n'importe quelle autre bibliothèque. Tout ce que la FAQ est en train de dire, c'est que même "statiquement" lié programmes ont certains bibliothèques liées de manière dynamique. Il ne dit pas que la liaison statique est "impossible" ou qu'il "ne fonctionne pas".

    • Cela signifie qu'il n'est pas complètement l'accumulation d'électricité statique. En fait, dans la plupart des cas, il aura besoin de la même version de la glibc pour être installé afin de fonctionner correctement. Et pourquoi ai-je besoin d'une telle accumulation d'électricité statique?
    • statiquement construire des exécutables n'ont pas l'éditeur de liens dynamiques ainsi, ne peut pas charger les bibliothèques partagées. Meilleure référence que j'ai pu trouver: en.wikipedia.org/wiki/Static_build . Comme je l'ai écrit ci-dessous, Linux ne supporte pas intentionnellement.
    • La fin du jeu, mais lorsque l'on travaille sur des systèmes rigides où, disons le compilateur c++ sur un système ne prend en charge C++98, et le code écrit en C++11 est porté... pour le compiler sur une RHEL 6 système qui prend en charge le C++0x, puis de copier le binaire à l'ancienne RHEL 5 système qui ne supporte pas C++0x.. si je pouvais lien statique de l'ensemble de l'application, puis il irait sur la RHEL 5 système. Pourquoi, par exemple, la liaison statique est utile. Mais je ne peux pas, parce que, pour une fois, il n'y a pas de G++ options du compilateur g++ 4.4.7 lien statique dans les bibliothèques C++.
    InformationsquelleAutor Dean Harding
  5. 13

    Liaison statique est de retour sur la montée!

    • Beaucoup (la plupart?) Aller langage de programmation exécutables sont liées statiquement.
      • L'augmentation de la la portabilité et la compatibilité descendante est une des raisons pour eux d'être populaire.
    • D'autres langages de programmation ont les mêmes efforts pour faire la liaison statique vraiment facile, par exemple Haskell (je suis en train de travailler sur ce l'effort).
    • Configurable distributions Linux /package définit comme NixOS /nixpkgs permettent d'associer une fraction importante de leurs paquets de manière statique (par exemple, son pkgsStatic ensemble de paquets pouvons fournir toutes sortes de statiquement les exécutables).
    • Liaison statique peut résulter en une meilleure inutilisés-l'élimination du code au moment de la liaison, faire des exécutables plus petits.
    • libcs comme musl faire la liaison statique facile et correcte.
    • Quelques grands logiciels de l'industrie dirigeants d'accord sur ce point. Par exemple Google est l'écriture de nouvelles de la libc ciblées à liaison statique ("support statique non-PIE et de la statique-PIE linking", "nous n'avons pas l'intention d'investir à ce point [dans] le chargement dynamique et support de liaison").
    • Après près de 10 ans, depuis la première question qui se pose, c'est une bonne nouvelle. Personnellement, je vois l'avantage, depuis que je travaille dans une industrie réglementée, où les cibles embarquées, j'ai de moins en moins flexibles pour libc mises à jour. Mais je peux toujours fournir un nouveau binaire pour mon (entièrement) lié statiquement programme pour les appareils sur le terrain à tout moment.
    • Il serait juste de mentionner les inconvénients de la liaison statique (ralentissement de la vulnérabilité de fixation, un gonflement de l'package de mises à jour, l'augmentation de temps de liaison).
    • Augmentation de temps de liaison sont probablement vrai. Je ne pense pas que les autres sont universellement vrai. Statique vs dynamique n'a pas d'impact sur le vitesse de la vulnérabilité de la fixation, qui ne dépend que de qui travaille à fournir les mises à jour. Si une distribution fournit eux, ils sont tout aussi rapides, et si un tiers de leur offre, ils peuvent être plus rapide ou plus lent que votre distribution de choix. La taille des mises à jour dépendent de ce que vous comparant à d'. Normal pour une distribution comme Ubuntu, peut-être de transfert de moins de bytes avec des objets partagés, mais souvent, par exemple, Docker, les images doivent être mis à niveau de gros et sont plus statiques exe.
    • "Je ne pense pas que les autres sont universellement vrai" - probly mais même principe peut être appliqué à votre réponse) je suis à la recherche d'une position moyenne Linux desktop de l'utilisateur (qui utilise de la populaire distribution et peut-être quelques applications de développeurs tiers).
    • "Statique vs dynamique n'a pas d'impact sur la vitesse de la vulnérabilité de fixation ... si un tiers de leur offre, ils peuvent être plus rapide ou plus lent" - je dirais que fournisseur tiers, l'accent est mis sur SW fonctionnalités et/ou de la performance, la sécurité est plus un citoyen de deuxième classe. Et dans tous les cas, fournisseur tiers aurait à faire en double distribution de travail sur le suivi des questions de sécurité (ce qui signifie moins de ressources seront dépensés sur son produit).
    • "Normal distrib comme Ubuntu, peut-être de transfert de moins de bytes avec des objets partagés" - ouais, comme un utilisateur ordinaire, je m'intéresse principalement dans ce cas d'utilisation. "mais souvent, par exemple, Docker, les images doivent être mis à niveau de gros et sont plus statiques exe" - Support des images au moins peuvent être mis en cache (au moins partiellement) alors que statique exécutables doivent toujours être entièrement re-téléchargé sur chaque mise à jour.

    InformationsquelleAutor nh2
  6. 10

    D'y ajouter d'autres réponses:

    Pour les raisons dit dans les autres réponses, il n'est pas recommandé pour la plupart des distributions Linux, mais il ya effectivement des distributions qui sont faites spécifiquement pour exécuter lié statiquement binaires:

    De stali description:

    statique linux est basée sur une main sélectionné les meilleurs outils
    pour chaque tâche et chaque outil lié statiquement (y compris certains X
    des clients tels que st, surf, dwm, dmenu),

    Il cible également binaire réduction de la taille grâce à l'évitement de la glibc
    et d'autres pléthorique des bibliothèques GNU lorsque cela est possible (les premiers essais montrent
    que statiquement binaires sont généralement plus petits que leurs
    liée de façon dynamique la glibc homologues!!!). Remarque, c'est à peu près
    contrairement à ce que Ulrich Drepper, estime à propos de la liaison statique.

    En raison de la côté-avantage lié statiquement binaires de démarrer plus rapidement,
    la répartition cible également les gains de performance.

    La liaison statique contribue aussi à la réduction de la dépendance.

    Vous pouvez en lire plus à ce sujet dans cette question de la statique vs dynamique reliant.

    InformationsquelleAutor Farid Nouri Neshat