Discussion :

[Shinja]

Bonjour, je viens demander l'avis de spécialiste car depuis une semaine je me retrouve confronter à un problème concernant mon binaire 32 et 64-bits que j'aimerais rendre compatible avec le maximum de distributions.

Pour faire mes tests, j'utilise une machine virtuelle avec Fedora et Ubuntu. Je compile depuis ArchLinux et le soucis c'est que je dispose des dernières libs. Du coup, mon binaire requière des versions récentes de ces librairies et il est donc impossible de le lancer sur des anciennes versions d'Ubuntu et Fedora. La seule parade que j'ai trouvé, est de lier le maximum de libs pour l'archive binaire. En revanche pour le paquet DEB d'Ubuntu, je n'ai linké statiquement que libjpeg mais il faut disposer de la dernière version d'Ubuntu qui embarque glibc 2.17. Pour Fedora, j'ai dû compiler depuis la machine virtuelle car la FC18 embarque glibc 2.16.

J'ai essayé de linker statiquement glibc, mais sans succès. Par contre, lors de mes essais, j'avais tenté de fournir glibc 2.15 dans le dossier du binaire et étrangement le binaire 64-bits se lançait sur de vielles distributions. J'ai pensé que c'était justement grâce à lib dans le dossier mais après sa suppression, le binaire se lance quand même. Alors je ne sais pas trop ce qui a bien pu se passer car en regardant les paramètres de g++, je ne vois rien de spécial. Quant à la version 32-bits, impossible de la faire tourner sans glibc 2.17.

Bref, je ne sais plus trop quoi faire et je me vois mal m'amuser à compiler pour chaque distribution selon les versions des libs. D'autant plus que sous ArchLinux, les mises à jours arrivent vite.

Y a t-il une solution pour éviter ce genre de soucis? Merci

[becket]

Oui, programmer cela en java parce que dans ce cas, tu sera presque indépendant de l'os qui est derrière (pour autant que la machine virtuelle java soit installée )

[troumad]

Et si tu livrais un programme à compiler ?

[marc.collin]

tu pourrais soit tout ou presque mettre en statique

sinon

suse propose obs qui permet de construire ton paquet pour de nombreuse distribution: suse, ubuntu, fedora, mandriva.......

[gangsoleil]

Bref, je ne sais plus trop quoi faire et je me vois mal m'amuser à compiler pour chaque distribution selon les versions des libs. D'autant plus que sous ArchLinux, les mises à jours arrivent vite.

En vrac :

• Arreter de dependre des dernieres versions, qui ne sont jamais disponibles en meme temps sur les differentes distributions. D'ailleurs, la plupart du temps, le gain est minime.
  
• Linker avec des librairies statiques, et non dynamique. Tu perds l'upgrade automatique des librairies, mais en meme temps tu vas gagner en stabililite, car il existe encore beaucoup de librairies qui ne sont pas reellement backward compatibles.
• Et puis ca permet a l'utilisateur d'avoir ton programme qui necessite absolument la 2.17.4.78.32 et l'autre programme qui necessite la 2.17.4.78.315, qui ne sont pas compatibles.
  
• Mettre les sources en telechargement, avec des fichiers pour les outils de build, type cmake ou autotools. Ah bien sur, il faut que l'utilisateur ait ces outils, ainsi que les dernieres versions des libs externes.
  
• Embarquer les libs dynamiques pour les poser dans ton repertoire, ce qui a presque les memes avantages/inconvenients que les libs statiques, si ce n'est que toutes les libs dynamiques ne sont pas disponibles en statique.

[Shinja]

Merci pour vos réponses ! En effet, je n'ai pas trop le choix du statique. Cependant, j'avais mis la dose de librairies statiques dans mon binaire, sauf que la version 32-bits voulait toujours glibc 2.17 tandis que la x86_64 fonctionne très bien indépendamment. Cela fait trois jours que je n'ai pas arrêté de faire des tests dans tous les sens et j'ai enfin réussie. C'est assez complexe de savoir qui est la librairie qui vient me rajouter des dépendances. Heureusement, ldd existe et ma indiqué qui était le trouble fête. Je l'ai recompilé à ma sauce, j'ai lancé le binaire dans une machine virtuelle avec Ubuntu 12.04 d'installé et tout s'est lancé sans embrouille.

D'un coté je suis un peu déçu de ce système car cela demande pas mal de temps de configuration et de recherches alors que tout pourrait être plus simple si toutes les distributions pointaient vers les mêmes versions. A moins de libérer des sources et laisser les utilisateurs se débrouiller comme des grands, cela demande un travail supplémentaire. Enfin, l'essentiel c'est que le binaire ce lance sur la majorité des distributions.

Le problème des sources, se sont les utilisateurs qui ont peu de connaissances et n'ont pas envie d'apprendre à compiler / installer les outils nécessaires. Je pense que c'est important pour un utilisateur lambda qui utilise son ordinateur comme desktop à la manière d'un Windows. Je pense que c'est important de se soucier de ces personnes là qui veulent un truc qui marche au premier clique...

[gangsoleil]

Le problème des sources, se sont les utilisateurs qui ont peu de connaissances et n'ont pas envie d'apprendre à compiler / installer les outils nécessaires. Je pense que c'est important pour un utilisateur lambda qui utilise son ordinateur comme desktop à la manière d'un Windows. Je pense que c'est important de se soucier de ces personnes là qui veulent un truc qui marche au premier clique...

Qu'est-ce qui t'empeche de distribuer les sources, et que l'executable de lancement soit un scipt, qui verifie si les sources ont ete compilees, et si ce n'est pas le cas qui les recompile ?

mon_executable : un script qui verifie la presence de bin/mon_binaire : si present, il le lance, si pas present, il compile puis le lance.

[Shinja]

Qu'est-ce qui t'empeche de distribuer les sources, et que l'executable de lancement soit un scipt, qui verifie si les sources ont ete compilees, et si ce n'est pas le cas qui les recompile ?

mon_executable : un script qui verifie la presence de bin/mon_binaire : si present, il le lance, si pas present, il compile puis le lance.

Tout simplement parce que mon programme n'est pas libre, ni open-source. Il est distribué sous licence CC-BY-NC-ND.