Question Les distributions Linux sont-elles compatibles entre elles?


En d'autres termes, une application qui s'exécute sur une même distribution peut-elle être simplement copiée et exécutée sur une autre distribution?


4
2018-03-09 15:09


origine




Réponses:


Cela dépend de la manière dont l'application est créée. Un problème peut être des chemins de système qui peuvent différer d'une distribution à l'autre. Un autre problème concerne les bibliothèques partagées qui peuvent ne pas être installées sur le système cible ou, pire, peuvent être installées dans des versions incompatibles.

Une solution au problème des bibliothèques consiste à créer des binaires liés statiquement ou (comme cela est courant sur OS X) à envoyer toutes les librairies requises avec l'application et à définir LD_LIBRARY_PATH si nécessaire (même si c'est une mauvaise idée pour tant de raisons).

Un moyen simple de vérifier si votre programme s'exécutera est de répertorier toutes les bibliothèques liées utilisant ldd et de voir si elles existent sur le système cible.

Exemple utilisant apache httpd:

[lukas@web1 /]$ ldd /usr/sbin/httpd
        libm.so.6 => /lib64/libm.so.6 (0x00002b1ec3aaf000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00002b1ec3d32000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b1ec3f4e000)
        libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00002b1ec4167000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b1ec4384000)
        libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002b1ec45bc000)
        liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002b1ec47f7000)
        libdb-4.3.so => /lib64/libdb-4.3.so (0x00002b1ec4a05000)
        libexpat.so.0 => /lib64/libexpat.so.0 (0x00002b1ec4cfa000)
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00002b1ec4f1d000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b1ec5144000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b1ec535f000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b1ec5564000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b1ec58bb000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b1ec3892000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b1ec5b01000)
        libpq.so.4 => /usr/lib64/libpq.so.4 (0x00002b1ec5d06000)
        libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00002b1ec5f28000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b1ec6183000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002b1ec6399000)
        libssl.so.6 => /lib64/libssl.so.6 (0x00002b1ec65b2000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b1ec67fc000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b1ec6b4e000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b1ec6de3000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b1ec6ffc000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b1ec722a000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b1ec742c000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002b1ec7652000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b1ec7866000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b1ec7a6e000)

Si toutes les bibliothèques liées existent dans une version compatible sur le système cible, il est probable que votre application pourra démarrer. A partir de là, il y a surtout des chemins à ajuster.


5
2018-03-09 15:39



Bonne réponse! Le mot "probable" est également important dans cette réponse. Même si ldd est heureux (toutes les dépendances remplies) votre application peut ne pas fonctionner comme prévu car quelque chose dans l'une des bibliothèques de dépendance n'est pas ABI compatible. pour plus de lecture, voici un exemple: access.redhat.com/articles/rhel-abi-compatibility - Trevor Boyd Smith


Cela dépend entre autres de la version glibc. C'est généralement ne pas une bonne idée de ce que les structures de système de fichiers peuvent varier.


3
2018-03-09 15:19





Cela dépend de la complexité de l'application, ainsi que des dépendances et des bibliothèques auxquelles elle est liée.

Si l'application est autonome, simple, ne comporte pas de dépendances externes et est compilée sur la même architecture de processeur, elle devrait fonctionner.

Dans des scénarios plus compliqués, il est difficile de dire. Bien sûr, pour avoir la moindre chance, l’application doit être pour le même processeur, la même version de glibc, et les 2 distributions doivent avoir une base commune - c’est-à-dire qu’elle est plus facile à exécuter sur Ubuntu, etc.

Si vous voulez créer une telle application et pouvoir l'exécuter sur n'importe quelle distribution, vous devez la compiler avec des bibliothèques liées statiquement, et ne pas relayer sur la disposition du système de fichiers du système d'exploitation et supposer que certains fichiers seront localisés Emplacements.

Id ce n'est pas vous qui construit l'application - alors mieux utiliser les paquets de pré-construction de la distribution spécifique, ou compiler à partir des sources.

Tout ce qui précède est vrai pour les applications "compilées". S'il s'agit d'une application de langage de script - ruby, php, perl, python, etc. (probablement si la version de l'interpréteur est la même), vous pouvez simplement la copier - si l'application ne suppose pas que certains fichiers se trouvent à des emplacements spécifiques. Mais cela peut être résolu, car vous pouvez modifier le script pour l'adapter au mouvement.


2
2018-03-09 15:25





Si l'architecture du processeur est la même, je ne vois pas pourquoi cela ne fonctionnerait pas.


0
2018-03-09 15:14



Cela dépend vraiment de la façon dont l'application a été construite. Dans le cas le plus général, même sur la même architecture de processeur, cela ne fonctionnera pas - Dominik
ex: l'application construite sur MS Windows ne fonctionnera pas sur Apple OSX même si les deux peuvent avoir la même architecture x86_64. - Trevor Boyd Smith