Si je lier statiquement un exécutable dans ubuntu, y a-t-il une chance que cet exécutable ne fonctionne pas dans une autre distribution telle que mento os? ou Fedora? Je sais que les types de processeurs sont affectés, mais à part ça, y a-t-il autre chose dont je dois me méfier? Désolé si c'est une question stupide. Merci pour toute aideLa liaison statique sur une distribution unix fonctionnera-t-elle mais pas une autre?
Si vous liez statiquement un programme sur un ordinateur, puis que vous le déplacez vers un autre ordinateur sur lequel le système fonctionne essentiellement de la même manière, cela devrait fonctionner correctement. C'est le point de la liaison statique; qu'il n'y a pas d'autres fichiers dont dépend le programme - il est entièrement autonome, aussi longtemps qu'il peut fonctionner, il fonctionnera de la même manière que sur son système "hôte". Cela contraste avec la liaison dynamique, dans laquelle le programme incorpore des éléments d'autres fichiers (bibliothèques) au moment de l'exécution. Si vous déplacez un programme lié dynamiquement vers un autre système où les bibliothèques dont il dépend sont différentes (ou inexistantes), cela ne fonctionnera pas.
C'est la mauvaise réponse, surtout sur Linux. Si cette réponse "gagne", alors stackoverflow est inutile :-( –
-1: Il n'y a pas que l'architecture de l'ordinateur en jeu. –
Je me suis trompé, quand j'ai écrit "architecture", je pensais plus à l'architecture des puces. –
Dans la plupart des cas, votre exécutable fonctionne correctement. Tant que votre exécutable ne dépend pas de quelque chose d'inhabituel pour qu'il fonctionne, il n'y aura pas de problème. (Et, si cela dépend de quelque chose d'inhabituel étant présent, alors vous aurez le même problème, même si vous liez dynamiquement.)
La liaison statique est généralement plus sûre que la liaison dynamique pour la compatibilité entre différents environnements UNIX, aussi longtemps que le même processeur est utilisé. Pour faire échouer un binaire lié statiquement, en supposant encore la même architecture de processeur, vous devez faire quelque chose comme un lien sur un système utilisant le format binaire a.out et essayer de l'exécuter sur un système exécutant ELF, dans Dans ce cas, la version liée dynamiquement échouerait tout aussi mal.
Alors, pourquoi les personnes et sont-elles systématiquement connectées de manière statique? Deux raisons:
Il y a quelques cas de coin, mais pour la plupart, vous devriez être en bonne forme avec la liaison statique. Celui qui me vient à l'esprit est libnss. Cette bibliothèque particulière est essentiellement impossible à lier statiquement, en raison de la façon dont elle fait son travail (autorisations, authentification, tâches de sécurité). Tant que les versions de la glibc sont similaires, vous devriez avoir raison sur ce problème. Si votre programme doit fonctionner avec des fonctionnalités subtiles du noyau, comme les gestionnaires de volume, vous avez peu de chance de faire fonctionner votre programme, lié statiquement, entre les distributions, car les interfaces du noyau peuvent changer légèrement.
La plupart des applications typiques, qui ont même un sens pour discuter de la portabilité, comme les services réseau, les applications graphiques, les outils de langage (comme les compilateurs/interprètes) ne rencontreront aucun problème.
Une nouvelle glibc vous avertira si vous liez statiquement une des fonctions du "problème" Pour trouver la liste complète, vous pouvez faire "stings -a /usr/lib/libc.a | grep" statiquement Cela me donne 73 fonctions sur Fedora 9. NE PAS ignorer cet avertissement, ou vous allez planter et graver! –
Au contraire. Quelles que soient vos chances de faire fonctionner un binaire à travers les distributions ou même les systèmes d'exploitation, ces chances sont maximisées par un lien statique. La liaison statique rend un fichier exécutable autonome en termes de bibliothèques. Il peut encore tourner mal s'il essaie de lire un fichier qui n'existe pas sur un autre système.
Pour encore plus de chances de portabilité, essayez de vous lier à dietlibc ou à une autre libc. An article at Linux Journal mentionne quelques candidats. Une libc plus petite et plus simple est moins susceptible de dépendre de choses dans le système de fichiers qui diffèrent de distro à distro.
+1 pour souligner que l'utilisation d'une libc plus petite est souvent un bon choix. Beaucoup d'installations depuis la glibc est assez énorme, vous aurez d'énormes binaires. –
Je voudrais, pour les raisons indiquées ci-dessus, éviter de lier statiquement quelque chose à moins que vous absolument doit. Cela étant dit, cela devrait fonctionner sur n'importe quel noyau similaire de la même architecture (si vous liez statiquement sur une machine sous linux 2.4.x, le chargeur VDSO sera différent sur Linux 2.6, VDSO étant virtuel objet partagé dynamique, un objet partagé que le noyau expose à chaque processus contenant du code loader).
D'autres pièges comprennent des choses dans/etc ne pas être où vous penseriez, des bûches dans des endroits différents, des utilitaires système étant absents ou différents (ubuntu utilise update-rc.d, RHEL utilise chkconfig), etc.
Il arrive parfois que vous n'ayez pas le choix. J'écrivais un programme qui parlait à l'interface cmdlib basée sur les chaînes de LVM2 en faveur de l'utilisation d'execv() .. bas et voici, 30% des distributions que je devais supporter n'incluaient PAS cette bibliothèque et ne proposaient aucun moyen de l'obtenir. Donc, j'ai dû faire un lien avec l'objet statique lors de la production de paquets binaires.
Si vous utilisez glibc, vous pouvez être sûr que des choses comme getpwnam() et continueront à fonctionner .. assurez-vous juste de regarder tous les chemins codés en dur (mieux encore, de les rendre configurables à l'exécution)
Tant que vous pouvez garantir qu'il ne sera exécuté que sur une version similaire du système d'exploitation sur un matériel similaire, votre programme fonctionnera très bien s'il est lié statiquement. Donc, si vous construisez un Linux 2.6 et un lien statiquement, vous pouvez utiliser (presque) toutes les distributions Linux 2.6. Attention, vous ne pouvez pas lier de manière statique certaines parties de GLIBC, donc si vous les utilisez, vous devrez relier dynamiquement de toute façon. De mémoire les pièces de nom de service (nss) ont exigé la liaison dynamique quand je l'enquêtais.
Vous ne pouvez pas lier statiquement un programme pour Linux (par exemple) alors attendez-vous à ce qu'il fonctionne sur BSD ou Windows. BSD et Unix ne présentent ni ne traitent leurs appels système de la même manière que Linux. Je dis un léger mensonge parce que les BSD ont une couche d'émulation Linux qui peut être activée, mais cela ne marchera pas.
Non, cela ne fonctionnera pas. La liaison statique pour l'indépendance de distribution est un concept issu des anciens âges Unix et n'est pas recommandée. Par le fait que vous ne pouvez pas autant de bibliothèques ne sont pas disponibles en tant que bibliothèques statiques de toute façon. Suivez la norme Linux Standard Base, c'est votre seule chance d'obtenir autant de portabilité de la distribution croisée que possible. Le LSB fonctionne également très bien si vous programmez pour FreeBSD et Solaris.
Deux questions de compatibilité sont en cause ici: les versions de la bibliothèque et l'inventaire de la bibliothèque.
Vous ne dites pas quelles bibliothèques vous utilisez.
Si vous avez aucune option « -l », alors la seule « bibliothèque » est lui-même glibc, qui sert de l'interface au noyau. Les versions de Glibc sont compatibles vers le haut. Si vous faites un lien sur un système glibc 2.x, vous pouvez utiliser une glibc 2.y, pour y> x. Les développeurs s'engagent fermement à cela.
Si vous avez des options -l, la liaison statique est toujours sûre. Si vous êtes lié dynamiquement, vous devez vous assurer que (1) la bibliothèque est présente sur le système cible et (2) a une version compatible. Votre kilométrage peut varier selon que la distribution cible possède ce dont vous avez besoin.
Belle question. Quelque chose que je pensais aujourd'hui. – TheHippo
Par "unix", êtes-vous sûr de ne pas vouloir dire "linux"? – bk1e