Mon binaire linux fonctionnera-t-il sur toutes les distributions?

J'ai trouvé un bon IDE de remplacement pour Delphi appelé Lazarus. Mais je n'ai pas de question pour les programmeurs.

Le binaire Linux lié statiquement fonctionnera-t-il sur toutes les distributions Linux? Autrement dit, peu importe sur quelle distribution Linux je l'ai construit et cela fonctionnera sur Debian / ArchLinux / Ubuntu / OpenSUSE / ... quoi que ce soit?

À la suite de mes découvertes, est-ce vraiment important que 32 bits contre 64 bits? Je veux être sûr avant de publier.

Cette réponse a d'abord été écrite pour la question plus générale "mon binaire fonctionnera-t-il sur toutes les distributions", mais elle traite des binaires liés statiquement dans la seconde moitié.

Pour tout ce qui est plus complexe qu'un monde bonjour lié statiquement, la réponse est probablement non .
Sans le tester sur la distribution X, supposez que la réponse est non pour X.

Si vous souhaitez envoyer votre logiciel sous forme binaire, limitez-vous à

• quelques distributions populaires pour le domaine d'utilisation de vos logiciels (desktop, serveur, embarqué, ...)

• la dernière ou les deux dernières versions de chaque

Sinon, vous vous retrouvez avec des centaines de distributions de toutes tailles, versions et âges (une distribution de dix ans est toujours utilisée et prise en charge).

Testez-les. Juste un petit pointeur sur ce qui peut (et va) mal tourner autrement:

• Le package d'un outil / bibliothèque dont vous avez besoin est nommé différemment selon les distributions et même les versions de la même distribution

• Les bibliothèques dont vous avez besoin sont trop récentes ou trop anciennes (mauvaise version). Ne présumez pas simplement que votre programme peut créer un lien, il est lié à la bonne bibliothèque.

• La même bibliothèque (fichier sur disque) est nommée différemment sur différentes distributions, ce qui rend la liaison impossible

• 32 bits sur 64 bits: l'environnement 32 bits peut ne pas être installé ou une bibliothèque 32 bits non essentielle est déplacée dans un package supplémentaire en dehors de l'environnement 32on64, vous avez donc une dépendance supplémentaire juste pour ce cas.

• Shell: n'assumez pas votre version de Bash. Ne présumez même pas Bash.

• Outils: ne supposez pas qu'un outil de ligne de commande non POSIX existe n'importe où.

• Outils: ne présumez pas que l'outil reconnaît une option simplement parce que la version GNU de votre distribution le fait.

• Interfaces du noyau: ne présumez pas l'existence ou la structure des fichiers /procsimplement parce qu'ils existent / ont la structure sur votre machine

• Java: êtes-vous vraiment sûr que votre programme fonctionne sur JRE d'IBM tel qu'il est livré avec SLES sans le tester?

Prime:

• Jeux d'instructions: le binaire compilé sur votre machine ne fonctionne pas sur un matériel plus ancien.

La liaison statique (ou: regroupement de toutes les bibliothèques dont vous avez besoin avec votre logiciel) est-elle une solution? Même si cela fonctionne techniquement, les coûts associés peuvent être trop élevés. Malheureusement, la réponse est probablement non plus.

• Sécurité: vous transférez la responsabilité de mettre à jour les bibliothèques de l'utilisateur de votre logiciel à vous-même.

• Taille et complexité: juste pour le plaisir, essayez de créer un programme GUI lié statiquement.

• Interopérabilité: si votre logiciel est un "plugin" de quelque nature que ce soit, vous dépendez du logiciel qui vous appelle.

• Conception de bibliothèque: si vous liez votre programme de manière statique à GNU libc et utilisez des services de noms ( getpwnam()etc.), vous vous retrouvez lié dynamiquement au NSS de libc (commutateur de service de noms).

• Conception de la bibliothèque: la bibliothèque avec laquelle vous liez statiquement votre programme utilise des fichiers de données ou d'autres ressources (comme les fuseaux horaires ou les paramètres régionaux).

Pour toutes les raisons mentionnées ci-dessus, les tests sont essentiels.

• Familiarisez-vous avec KVM ou d'autres techniques de virtualisation et disposez d'une machine virtuelle de chaque distribution que vous prévoyez de prendre en charge. Testez votre logiciel sur chaque machine virtuelle.

• Utilisez des installations minimales de ces distributions.

• Créez une machine virtuelle avec un jeu d'instructions restreint (par exemple, pas de SSE 4).

• Lien statique ou regroupé uniquement: vérifiez vos fichiers binaires avec lddpour voir s'ils sont réellement liés statiquement / utilisez uniquement vos bibliothèques regroupées.

• Lien statique ou groupé uniquement: créez un répertoire vide et copiez-y votre logiciel. chrootdans ce répertoire et exécutez votre logiciel.

La réponse est que cela dépend. , mais dans la plupart des cas, oui, tant que les bibliothèques nécessaires sont installées sur le système d'exploitation.

Généralement, la plupart des principales distributions comme celles que vous avez mentionnées ont leurs outils de gestion de packages qui installent la version communautaire de l'application. Cela prend en charge tous les packages prérequis dont l'application aura besoin. Si vous l'installez sans gestionnaire de packages, c'est à vous de vous assurer que tous les packages et bibliothèques nécessaires sont installés sur le système d'exploitation. C'est une bonne idée d'inclure une liste de ces applications prérequises dans la documentation.

Crappy answer first: Cela dépend

Si vous publiez des binaires, supposez que la réponse est «non», sauf si vous distribuez toutes les libs qu'il jamais implique avec elle ( à partir du sol, ce qui est gênant , sauf si vous fournissez un système vraiment énorme qui se dresse sur son propre de toute façon ) ou lient statiquement l'équivalent.

... mais les sorciers et l'argent, et les sorciers de l'argent ...

IBM a quelques installateurs "Unixish généraux" qui m'ont choqué en travaillant partout où je les ai essayés: plusieurs Linuces de plusieurs générations de noyau, OpenSolaris (ou peu importe comment on l'appelle maintenant), Solaris et BSD. Mais ils sont énormes. Et les choses qu'ils fournissent sont tout aussi énormes. Aucun petit programme de voitures de course ne sera publié de cette façon, juste les gros trucs de type entreprise que vous attendez d'IBM.

En ce qui concerne simplement rester sur Linux, mais fonctionnant bien dans la plupart des domaines Linux, cela semble possible sous forme binaire, comme en témoigne la variété des installateurs binaires de type "pour Linux (général)" que vous verrez chez certains fournisseurs. Plusieurs chats, navigateurs, jeux, méta-installateurs, etc. sont publiés de cette façon, mais toujours par d'énormes vendeurs qui peuvent passer le temps de bien faire les choses. C'est assez étonnant qu'ils puissent dire «pour Linux» et être généralement confiants que cela fonctionnera, mais cela semble être le cas.

Mais...

Je distribue mon logiciel comme source avec un utilitaire de build. Je le fais en C, Erlang, Python, Guile, etc. Cela me donne beaucoup plus de flexibilité pour savoir s'il fonctionnera ou non, et il est beaucoup plus facile d'écrire un buildscript qui s'assure que les bonnes choses existent au moment de la construction que assurez-vous que tout est en place au moment de l'exécution. Une fois que cela existe, il est trivial d'écrire un programme de mise à jour automatique pour votre programme si vous distribuez la source: la source est généralement beaucoup plus petite qu'un binaire qui inclut tous les deps et autres folie. En utilisant cette méthode, je n'ai pas eu beaucoup de mal à déployer de manière fiable sur Unices (et parfois Windows, mais c'est un peu plus une corvée).

Assez d'enfant, armez-vous!

Lorsque vous commencez sérieusement, comme srsly srs, à vous adapter sans problème au monde Linux, vous distribuez des sources C ou vous vous tournez vers un environnement entièrement géré pour un langage délicieusement piraté qui est déjà prédéfini. Si vous écrivez du code Python, par exemple, vous pouvez vérifier les versions et savoir avec quelle version CPython la vôtre fonctionne, et vous attendre généralement à ce qu'une version compatible existe sur un Linux donné (et c'est beaucoup plus facile à vérifier qu'un large balayage de C libs / versions que vous utilisez peut-être). Erlang, Guile, Python, Perl, CL, etc. sont tous très des cibles faciles pour ce type de déploiement, et beaucoup d'entre eux ont un référentiel central comme CPAN ou pip (ou autre) où les utilisateurs peuvent exécuter une commande pour extraire eux-mêmes la source signée quand ils le souhaitent, et savent que les choses fonctionneront généralement comme vous le souhaitiez .

[Addendum: 1. Même Haskell peut généralement retirer cela via Cabal - bien que je serais prudent à le faire dans un environnement de production. 2. Il existe des stratégies de déploiement de «version» totalement différentes avec Erlang qui garantissent que votre code emporte avec lui un environnement complet. 3. Python va plus loin avec les environnements virtuels; tous les temps d'exécution ne vous aident pas autant.]

Ce dernier morceau sur les environnements gérés sous Linux est vraiment génial . Et, en prime, il vous permet de définir des dépendances beaucoup plus générales, de les résoudre automatiquement sans effort supplémentaire de votre part, ne nécessite pas d'écrire un package par distribution et vous pouvez arrêter de vous soucier si un système est 32 ou 64 peu (généralement, de toute façon).