Objets partagés portables?

Question

Est-il possible d'utiliser des fichiers objet partagés de manière portable, comme les DLL sous Windows ??

Je me demande s’il est possible de fournir une bibliothèque compilée, prête à l’emploi, pour Linux. De la même manière, vous pouvez compiler une DLL dans Windows et l’utiliser sur n’importe quel autre Windows (ok, pas AUTRE, mais sur la plupart des cas, il le peut).

Est-ce possible sous Linux?

MODIFIER:
Je viens de me réveiller et de lire les réponses. Il y en a de très bons.
Je n'essaie pas de cacher le code source. Je veux juste fournir une bibliothèque déjà compilée et prête à être utilisée, afin que les utilisateurs qui n'ont aucune expérience de la compilation n'aient pas besoin de le faire eux-mêmes.
L’idée est donc de fournir un fichier .so qui fonctionne sur autant de Linux que possible.
La bibliothèque est écrite en C ++, à l’aide des bibliothèques STL et Boost.

Answer 1

Je fortement fortement recommande l'utilisation du vérificateur d'applications / de bibliothèques LSB. Sa va vous dire rapidement si vous:

• Utilisez des extensions qui ne sont pas disponibles sur certaines distributions
• Introduisez bash-isms dans vos scripts d'installation
• Utiliser des appels système qui ne sont pas disponibles dans tous les noyaux récents
• Comptez sur des bibliothèques non standard (cela vous indiquera les distributions qui leur manquent)
• Et beaucoup d'autres très bons chèques

Vous pouvez obtenir plus d'informations ici , ainsi que télécharger l'outil. Il est facile à utiliser .. décompressez-le simplement, exécutez un script Perl et pointez votre navigateur sur localhost .. le reste est piloté par le navigateur.

En utilisant cet outil, vous pouvez facilement obtenir la certification LSB de votre bibliothèque / application (pour les deux versions) et simplifier considérablement le travail de l’emballeur.

Au-delà de cela, utilisez quelque chose comme libtool (ou similaire) pour vous assurer que votre bibliothèque est installée correctement, fournissez un objet statique pour les personnes qui ne souhaitent pas créer de lien vers le DSO (il faudra du temps pour que votre bibliothèque apparaisse dans la plupart des distributions, écrivez donc un programme portable, je ne peux pas compter sur sa présence) et commentez bien votre interface publique.

Pour les bibliothèques, je trouve que Doxygen est ce qu'il y a de mieux. La documentation est très importante, elle influence certainement mon choix de bibliothèque à utiliser pour une tâche donnée.

Encore une fois, vérifiez le vérificateur d'applications, il vous donnera des rapports sur les problèmes de portabilité qui prendraient un an avant que la bibliothèque ne se trouve dans la nature pour obtenir le contraire.

Enfin, essayez de rendre votre bibliothèque facile à déposer "dans l’arbre", afin que je n’aie pas à établir de lien statique avec elle. Comme je l'ai dit, cela pourrait prendre quelques années avant que cela devienne commun dans la plupart des distributions. Il est beaucoup plus facile pour moi de simplement récupérer votre code, de le déposer dans src / lib et de l’utiliser, jusqu’à et si votre bibliothèque est commune. Et, s'il vous plaît, donnez-moi des tests unitaires, TAP (testez le protocole), est un bon moyen portable de le faire. Si je pirate votre bibliothèque, j'ai besoin de savoir (rapidement) si je l'ai cassée, en particulier lorsque je la modifie en arborescence ou en situ (si le DSO existe).

Answer 2

Si vous souhaitez aider vos utilisateurs en leur fournissant du code compilé, le meilleur moyen que je connaisse est de leur fournir un binaire lié de manière statique + une documentation leur expliquant comment exécuter le binaire. (Ceci est peut-être en plus de leur donner le code source.) La plupart des fichiers binaires liés de manière statique fonctionnent sur la plupart des distributions Linux de la même architecture (les fichiers binaires liés de manière statique à 32 bits (x86) fonctionnent sur un système 64 bits (amd64)). Il n’est donc pas surprenant que Skype propose un téléchargement Linux lié statiquement.

Retour à votre question sur la bibliothèque. Même si vous êtes un expert en écriture de bibliothèques partagées sous Linux et que vous prenez le temps de minimiser les dépendances pour que votre bibliothèque partagée fonctionne sur différentes distributions Linux, y compris les anciennes et les nouvelles versions, rien ne garantit que cela fonctionnera. dans le futur (disons 2 ans). Vous finirez probablement par maintenir le fichier .so, c’est-à-dire faire de petites modifications à maintes reprises afin que le fichier .so devienne compatible avec les versions les plus récentes des distributions Linux. Ce n'est pas amusant de le faire pendant longtemps, et cela diminue considérablement votre productivité: le temps que vous passerez à maintenir la compatibilité de la bibliothèque aurait été bien mieux utilisé, par exemple. améliorer la fonctionnalité, l'efficacité, la sécurité, etc. du logiciel.

Notez également qu'il est très facile de contrarier vos utilisateurs en fournissant une bibliothèque au format .so qui ne fonctionne pas sur leur système. (Et vous ne disposez pas du super pouvoir pour le faire fonctionner sur tous tous les systèmes Linux, cette situation est donc inévitable.) Fournissez-vous également des versions 32 bits et 64 bits, y compris x86, PowerPC, BRAS etc.? Si le fichier .so ne fonctionne que sous Debian, Ubuntu et Red Hat (car vous n'avez pas le temps de le porter sur d'autres distributions), vous allez probablement énerver vos utilisateurs de SUSE et de Gentoo (et plus encore).

Answer 3

Idéalement, vous voudrez utiliser GNU autoconf , automake et libtool pour créer des scripts de configuration et de création, puis distribuez la bibliothèque en tant que source avec les fichiers configure et Makefile.in.

Voici un livre en ligne à ce sujet.

./ configure; faire; make install est assez standard sous Linux.

La racine du problème est que Linux s'exécute sur de nombreux processeurs différents. Vous ne pouvez pas simplement compter sur le processeur prenant en charge les instructions x86 comme Windows (pour la plupart des versions: Itanium (XP et versions ultérieures) et Alpha (NT 4.0) sont les exceptions).

Answer 4

La question est donc de savoir comment développer des bibliothèques partagées pour Linux. Vous pouvez consulter ce didacticiel ou le manuel de la bibliothèque de programmes Pogram .

Answer 5

Je sais ce que vous demandez. Pour Windows, MSFT a soigneusement rendu les DLL compatibles. Ainsi, vos DLL sont généralement compatibles avec presque toutes les versions de Windows. C’est pourquoi vous appelez cela "portable".

Malheureusement, sous Linux, il y a trop de variantes (et tout le monde pense être "différent" pour gagner de l'argent), de sorte que vous ne pouvez pas obtenir les mêmes avantages que Windows, et c'est pourquoi nous avons beaucoup de mêmes packages compilés pour différentes distributions. , version de distro, type de CPU, ...

Certains disent que le problème est dû à l'architecture (du processeur), mais ce n'est pas le cas. Même sur le même arc, il y a toujours des différences entre les distributions. Une fois que vous avez vraiment essayé de publier un paquet binaire, vous savez à quel point il est difficile - même la dépendance de la bibliothèque d'exécution C est difficile à maintenir. Le système d’exploitation Linux manque trop de matériel, de sorte que presque tous les services posent un problème de dépendance.

Généralement, vous ne pouvez construire que des binaires compatibles avec certaines distributions (ou plusieurs distributions si vous êtes chanceux). C’est pourquoi la publication de programmes Linux en binaire a toujours été foutue, sauf si elle est liée à une distribution comme Ubuntu, Debian ou RH.

Answer 6

Le simple fait de placer un fichier .so dans / usr / lib peut fonctionner, mais vous risquez de gâcher le schéma de votre distribution pour la gestion des bibliothèques.

Jetez un coup d’œil à la base standard linux - c’est ce qui se rapproche le plus d’une plateforme commune parmi les distributions linux.

http://www.linuxfoundation.org/collaborate/workgroups/lsb

Qu'est-ce que vous essayez d'accomplir?

Answer 7

La réponse de Tinkertim est parfaite. J'ajouterai qu'il est important de comprendre et de planifier les modifications apportées à l'ABI de gcc . . Les choses ont été assez stables récemment et je suppose que toutes les principales distributions sont sur gcc 4.3.2 ou à peu près. Cependant, au bout de quelques années, certains modifications apportées à l'ABI (en particulier les bits liés à C ++) semblent pour causer du chaos, au moins pour ceux qui souhaitent publier des binaires de distribution croisée et pour les utilisateurs qui ont pris l'habitude de ramasser des paquets d'autres distributions qu'ils ne le font réellement et qui trouvent qu'ils fonctionnent. Alors que l’une de ces transitions est en cours (toutes les distributions s’améliorent à leur propre rythme), vous souhaitez idéalement publier des bibliothèques avec des ABI prenant en charge l’ensemble des versions de gcc utilisées par vos utilisateurs.