La compatibilité binaire entre les distributions Linux

Question

Désolé si cela est une question évidente, mais je l'ai trouvé étonnamment peu de références sur le web ...

Je travaille avec une API écrite en C par l'un de nos partenaires commerciaux et nous a été fourni sous forme de fichier .so binaire, basé sur Fedora 11. Nous avons testé l'API sur une machine de développement Fedora 11 sans problèmes. Cependant, lorsque j'essaie de créer un lien avec l'API sur la plate-forme cible de notre client, qui se trouve être SuSE Enterprise 10.2, j'obtiens une erreur «Format de fichier non reconnu».

Les commandes qui font également partie du package binutils, telles que objdump ou nm, me donnent la même erreur de format de fichier. La commande « file » me montre:

ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped 

et la commande « ldd » montre:

ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1' 
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1) 
[dependent library list] 

Je devine que cela est dû à une incompatibilité entre les bibliothèques C sur les deux plates-formes, avec le Le problème étant que le code a été compilé avec une nouvelle version de glibc, etc., par rapport à celle disponible sur SuSE 10.2. Je publie cette question au cas où il y aurait un moyen de compiler le code sur la plate-forme Fedora 11 de notre partenaire de manière à ce qu'il fonctionne également avec SuSE 10.2.

Answer 1

Je pense que l'astuce consiste à construire sur une saveur de Linux avec les versions les plus anciennes du noyau et de la bibliothèque C de toutes les plates-formes que vous souhaitez prendre en charge. Dans mon travail, nous construisons sur Debian 4, ce qui nous permet de supporter officiellement Debian 4 et plus, RedHat 3,4,5, SuSE 10 plus diverses autres distributions (SELinux etc.) d'une manière non officielle.

Je suppose qu'en s'appuyant sur une nouvelle version de Linux, il devient difficile de supporter des personnes sur des machines plus anciennes.

(edit) Je devrais mentionner que nous utilisons le compilateur par défaut fourni avec Debian 4, qui est GCC 4.1.2. L'installation de versions plus récentes du compilateur tend à rendre la compatibilité bien pire.

Answer 2

Windows a-t-il des problèmes avec la compatibilité entre différentes réalités, service packs, SDK installés et DLL en général (DLL Hell, any?). Linux n'est pas immunisé contre les mêmes types de problèmes.

Les problèmes de compatibilité que j'ai vu comprennent:

• bibliothèque Runtime change
• Link Library change
• noyau change
• changements technologiques du compilateur (par exemple: avant et après les versions de gcc EGCS Cela pourrait. soyez votre problème).
• questions Packager (RPM contre APT)

Dans votre cas, je les aurais faire un « gcc -v » sur leur système et de vous communiquer le numéro de version gcc. Comparez cela à ce que vous utilisez.

Vous pourriez avoir à obtenir cette version du compilateur pour construire votre moitié avec.

Answer 3

Si le message est un format de fichier non reconnu, le problème est probablement mentionné par elmarco dans un commentaire - à savoir, une architecture différente. Il pourrait (je ne suis pas sûr) être une incohérence de version de lien dynamique, mais cela signifierait que le fichier .so a été construit avec un ancien éditeur de liens dynamique.Je ne crois pas que l'incompatibilité de la libc pourrait causer cela - ils pourraient causer des échecs de liaison et des problèmes d'exécution (très rarement), mais pas cela.

Answer 4

Je ne sais pas à propos de Suse, mais je sais que Fedora aime rester à la pointe. Donc, vous pouvez très bien avoir raison sur les versions de la bibliothèque. Pourquoi ne pas demander et voir si vous pouvez obtenir le code source et le construire sur votre machine Suse?

Answer 5

Vous pouvez utiliser Linux application outil de vérification ([1], [2], [3]) afin de résoudre les problèmes de compatibilité d'une application entre les distributions Linux. Il vérifiera vos formats de fichiers et toutes les bibliothèques dépendantes. Il prend en charge presque toutes les distributions Linux populaires, y compris toutes les versions de SuSE et Fedora.

Answer 6

Ceci est juste une opinion personnelle, mais quelque chose lors de la distribution en binaire uniquement former sous Linux, vous avez quelques options:

1. construire la gamme des .deb et .rpms pour chaque distribution sous le soleil, avec un paquet nominal ".tar.gz plein de binaires" pour tout ce que vous avez manqué. La première partie est idéale mais encombrante. La dernière partie vous mènera aux points 2 et 3.

2. Faites comme certains suggèrent et trouvent la plus ancienne distribution que vous pouvez trouver et construire là. Ma propre opinion est que c'est une sorte d'idée ridicule. Voir point 3.

3. Distribuez les fichiers binaires et statiquement le lien où vous le pouvez. Surtout pour libstdC++, ce qui semble être votre problème ici. Il y a apparemment beaucoup de versions incompatibles de libstdC++ flottant autour, ce qui en fait un cauchemar de compatibilité. Si vous ne pouvez pas lier statiquement, vous pouvez également placer des fichiers * .so à côté de votre binaire, et utiliser des éléments comme LD_PRELOAD ou LD_LIBRARY_PATH pour les lier préférentiellement à l'exécution. Notez que si vous empruntez cette route, vous devrez peut-être vous conformer à la LGPL, etc. puisque vous distribuez maintenant le travail d'autres personnes à côté de votre projet.

Bien sûr, la distribution de votre projet sous forme de source est toujours préférée sur Linux. :-)