Discussion :

[remi.a]

Bonjour

J'espère avoir bien choisi le forum pour cette question. Cela fait maintenant plus de dix ans que je développe et commercialise une application dédiée à la synthèse d'image. Cette application sous licence commerciale, programmée en C++ et utilisant wxWidgets / OpenGl, est disponible pour la plateforme windows et OSX (je peux vous envoyer le lien du site de mon appli par msg privé pour les curieux). J'aimerais maintenant me lancer dans le portage linux.

Sous windows, la distribution de mon appli C++ a été une tache plutot facile, il suffit de fournir le vc_redist.exe dans le setup de l'appli et ça roule la plus part du temps. Sur linux, il semblerait que les choses ne soient pas si évidentes. Sous linux il me semble que se pose la question d'un choix éventuel de la distribution (Fedora/ubuntu etc...), du choix de la version de gcc, et, si j'ai bien compris de la version de la glibc (si j'ai bien compris).

Mon objectif est simple : Choisir la distribution de développement, le compilateur et d'autres choses s'il le faut, afin que l’exécutable produit soit compatible sur un maximum de distribution linux possible.

Problème : je n'ai pas une expérience suffisante pour déterminer ces paramètres à l'avance, et j'aimerais éviter de les trouver de manière itérative, vu le temps que ça prendrait de tester toutes les configurations de distribution de développement et de distribution d exécution...

Quelqu'un aurait-il de l expérience à partager ? Des documents / liens ?

Merci

Rémi Arquier

[Obsidian]

Hello,

La bonne nouvelle, c'est que OpenGL, wxWidget et le C++ en général sont trois technologies très largement répandues, éprouvées et utilisées sous Linux. Donc, si tu n'utilises rien de plus spécifique en soi, tu ne devrais pas avoir de problème à porter ton logiciel. Tu n'as pas besoin en soi de l'équivalent de vc_redist.exe car toutes les bibliothèques sont en principe libres et intégrées à la distribution. Si une dépendance est manquante, le système de package est capable de la cibler et d'aller automatiquement télécharger (avec accord de l'utilisateur) les composants requis, un peu à la manière d'un Windows Update.

Les problèmes que tu risques de rencontrer sont :

• Les licences de distribution des différentes bibliothèques que tu utilises. La plupart sont en LGPL ou assimilées, ou BSD, et ne posent pas de problème. Par contre, les bibliothèques en GPL pure obligent les logiciels qui l'utilisent à être eux-mêmes publiés en GPL. A priori, rien de tel : la GNU lib C++ est en « GPL avec exception » (donc une sorte de LGPL, si ce n'est pas la même chose), wxWidget est officiellement en LGPL et l'implémentation d'OpenGL dépend de ce qui la fait tourner (pilotes proprio nVidia ou émulation logicielle avec MESA, laquelle est sous licence X11 MIT, très permissive) ;
• Les problèmes d'intégration. D'une distribution à l'autre, les logiciels sont en général les mêmes, mais il arrive qu'elles proposent — en plus — leur propre suite et surtout, elles choisissent toutes un système de package, le plus souvent *.deb ou *.rpm et un environnement de bureau par défaut (KDE, Gnome, ou d'autres). Ce sont surtout ces points qu'il faudra soigner, mais disons que si tu maintiens au moins les formats *.deb et *.rpm, et que tu proposes en plus une archive *.tar.gz ou *.tar.bz2 (l'équivalent d'un *.zip), pour que le reste des utilisateurs puisse éventuellement se débrouiller, tout le monde devrait y trouver son compte.

La version des bibliothèques est effectivement importante, d'autant plus qu'elles évoluent vite et qu'il arrive qu'elles introduisent des incompatibilité. L'avantage est qu'avec les produits que tu as choisis, tu ne risques pas de te retrouver avec solutions concurrentes mais incompatibles entre elles. Tu devrais sans risque les retrouver sur toutes les plateformes.

Je te conseille d'installer au moins une Fedora et une Ubuntu (basées respectivement sur Red Hat en RPM et Debian en Deb) dans une machine virtuelle et d'essayer d'y compiler et/ou d'exécuter tes exécutables finaux directement dedans. Ensuite, downgrade les bibliothèques disponibles à l'aide du système de package, ce qui te permettra de savoir jusqu'où tu peux descendre, ce qui te permettra de déterminer un numéro de version minimum à fournir au gestionnaire de package.

Ensuite, l'idéal est de faire la même opération sur des versions plus anciennes de chaque distrib pour voir si ton programme compile toujours : il est tout-à-fait possible que les bibliothèques soient compatibles de longue date mais que pour des raisons d'optimisations, leurs ABI cessent de l'être d'une version majeure à l'autre. Comme sur tous les systèmes, on essaie de faire en sorte que cela n'arrive que rarement, mais comme sous Linux, les logiciels sont censés être libres, donc potentiellement recompilés si nécessaires, voire même corrigés par leurs utilisateurs, ce point a un peu moins d'importance que sur des systèmes propriétaires, fermés mais certifiés.

[remi.a]

Merci beaucoup pour cette réponse détaillée.

J'ai des questions.

1/ En ce qui concerne le développement et le test de compatibilité, tu me dis de télécharger une version récente d'une distrib et de downgrader les bibliothèques afin de déterminer le numéro de version compatible le plus ancien. Mais là, tu parles des bibliothèques avec lesquelles je vais *linker* le programme ou celles qui font *tourner le système* lors de l'exécution du soft ?

2/ Le downgrade des bibliothèques n'est-il pas une source de problème ? est-il possible d'installer plusieurs versions simultanément de ces libs sur le meme OS ? Dans le fond, n'est-ce pas plus simple d'installer et de compiler sur une "vieille" fedora 14 par ex, et de parier sur la compatibilité ascendante pour l exécution ?

3/ Pour les packages, je crois qu'un petit script bash avec les binaires dans un tar.gz me semble etre le plus simple compte tenu de mes connaissances. En même temps, le système de package .rpm ou .deb fournis la fonctionnalité de gestion des dépendances... Est-ce complexe de creer de tels packages ?

4/ Ce qui me fait *très* peur avec les lib partagées c'est que les utilisateurs vont faire tourner du code différent, selon leur distribution. Avec des libs statiques, tous les utilisateurs on le même code, du coup la chase au bug est plus facile. Y a t'il moyen de faire un gros binaire statique unique ? Est-ce une bonne idée selon toi ?


Merci encore.

[Obsidian]

Hello,

1/ En ce qui concerne le développement et le test de compatibilité, tu me dis de télécharger une version récente d'une distrib et de downgrader les bibliothèques afin de déterminer le numéro de version compatible le plus ancien. Mais là, tu parles des bibliothèques avec lesquelles je vais *linker* le programme ou celles qui font *tourner le système* lors de l'exécution du soft ?

Je parlais de celles du soft uniquement. Pour le reste, elles doivent être essentiellement les mêmes. Par exemple, on n'utilise pas d'artifice comme des *.lib en plus des *.dll lorsque l'on compile sous Linux. Les distributions, en revanche, ont l'habitude de séparer chaque bibliothèque en deux packages distincts « bibliotheque » et « bibliotheque-devel », mais ce n'est pas une obligation technique et le dernier des deux contient en général les headers C « *.h » et autres ressources qui ne sont pas nécessaires à l'exécution.

2/ Le downgrade des bibliothèques n'est-il pas une source de problème ?

En soi, si, puisque cela peut t'obliger à downgrader en cascade les autres logiciels qui sont sur ta distrib'. Mais pas d'inquiétude, tout cela est en principe géré par le système de package. Par contre, il faut faire cela à fins de test uniquement. Pas question bien sûr d'obliger l'utilisateur final à le faire.

est-il possible d'installer plusieurs versions simultanément de ces libs sur le meme OS ?

Oui. Tu peux même les déposer dans ton home ou dans le répertoire dédié à ton projet si tu en as besoin. Historiquement, sous UNIX, c'est la variable d'environnement LD_LIBRARY_PATH qui sert à indiquer où elles se trouvent, de la même façon que PATH indique où chercher les exécutables. Sous Linux, on utilise en plus « /etc/ld.so.conf » et la commande « ldconfig » pour faire un cache des bibliothèques système, mais rien de plus compliqué en ce qui concerne les dépôts.

Dans le fond, n'est-ce pas plus simple d'installer et de compiler sur une "vieille" fedora 14 par ex, et de parier sur la compatibilité ascendante pour l exécution ?

Non, ce n'est pas l'approche que je choisirais sur un Linux. Le système étant censé être libre en majorité, les bibliothèques sont débuguées et mises à jour en permanence. La compatibilité ascendance reste très importante mais si l'on est confronté à un cas nécessitant une refonte en profondeur, ce n'est pas un problème sous Linux, de tout recompiler au propre à partir de zéro. À dire vrai, certaines distributions comme Gentoo sont carrément basées sur ce principe : au départ, il n'y a pour ainsi dire aucun binaire précompilé : tout est généré automatiquement et en direct sur la machine de l'utilisateur. Les compilateurs, eux, sont faits pour en tenir compte.

Par contre, certaines distributions, et spécialement Fedora, sont faites pour être volontairement on the edge, voire expérimentales. Il se peut alors que tu te retrouves dans un environnement qui soit loin de représenter la majorité des distributions et de ce qui fait un Linux. Par exemple, il y a une grande migration en cours de SysVInit vers SystemD qui ne se fait pas sans douleur et qui provoque beaucoup d'émoi dans la communauté.

Quoi qu'il en soit, tu ne devrais pas être gêné par tout cela à ton niveau : tant que t'en tiens aux bibliothèques que tu nous as cité, il faut juste veiller à faire du code qui soit compatible avec la version majeure de ces bibliothèques et pas trop spécifique, si possible, à une sous-version donnée. Les propres dépendances de ces bibliothèques, elles, seront gérées par les mainteneurs de la distrib' ou par les bibliothèques elles-mêmes.

D'expérience, les applications que j'ai compilées il y a six ou sept ans avec OpenGL fonctionnent encore aujourd'hui sans adaptation particulière. Le seul problème que je rencontre avec un binaire est avec le jeu Terminus sur ma machine 64 bits sous Fedora 17, sans succès. Il est de fait que le binaire date de 1999 et a donc 13 ans.

L'exécutable est bien reconnu même s'il est naturellement en 32 bits, et les bibliothèques sont présentes, là encore en 32 bits puisque j'ai installé les bibliothèques de compatibilité. Par contre, mais c'est quand même la bibliothèque standard C++ qui me pose problème. Plusieurs symboles n'existent plus. J'ai essayé d'écrire une bibliothèque « tampon » qui fasse l'adaptation en comblant les lacunes. Ça fonctionne dans le principe mais je n'ai pas réussi à combler tous les trous.

J'ai la flemme de ressortir les anciens CD pour retrouver la version adéquate et, même là, il est probable qu'elle nécessite elle-même une version particulière de la GLibC, auquel cas ça va commencer à devenir compliqué de faire cohabiter tout cela avec le système actuel.

Quoi qu'il en soit, si tu dois recompiler ton programme une fois tous les dix ans sans avoir à le modifier, cela reste acceptable.

3/ Pour les packages, je crois qu'un petit script bash avec les binaires dans un tar.gz me semble etre le plus simple compte tenu de mes connaissances. En même temps, le système de package .rpm ou .deb fournis la fonctionnalité de gestion des dépendances... Est-ce complexe de creer de tels packages ?

Dans un premier temps, c'est effectivement le mieux à faire, autant pour toi que pour les utilisateurs.

Ensuite la création de packages a la réputation de ne pas être triviale parce qu'il faut passer beaucoup d'informations à l'empaqueteur, et que ces informations soient fiables. Mais à l'usage, il s'agit en fait de toutes les déposer dans un petit fichier texte qui va servir de roadmap à l'empaqueteur. Donc, tu l'écris une fois, et tu regénères ton package en une seule commande autant de fois que tu veux ensuite.

4/ Ce qui me fait *très* peur avec les lib partagées c'est que les utilisateurs vont faire tourner du code différent, selon leur distribution.

C'est là le principe : les distributions de Linux ne sont pas n systèmes similaires concurrents. Il s'agit toujours de Linux et les bibliothèques sont en principe les mêmes. Il ne s'agit pas de faire un portage sur chacune d'elles comme on le ferait entre SunOS et MacOS, par exemple.

Il n'en reste que tu ne peux bien sûr pas valider ton logiciel sur toutes les distributions existantes et encore moins sur toutes les versions de chacune d'elles. Mais pas d'inquiétude, ce seront généralement soit les mainteneurs de la distribution, soit parfois les utilisateurs eux-mêmes qui se chargeront de l'adapter. C'est pourquoi il faut faciliter la « faisabilité » de cette tâche. Le plus simple restant d'utiliser les technologies les plus conventionnelles possibles.

Avec des libs statiques, tous les utilisateurs on le même code, du coup la chase au bug est plus facile. Y a t'il moyen de faire un gros binaire statique unique ? Est-ce une bonne idée selon toi ?

À l'usage, non, ce n'est pas une bonne idée. D'abord pour les raisons que l'on connaît tous : impossibilité de mise à jour facile et logiciel vraiment très gros : si tu embarques tout OpenGL dans ton logiciel, il va commencer à devenir considérable.

Ensuite, OpenGL en particulier est plus qu'une simple bibliothèque : c'est une couche d'abstraction de fait et devenue très importante. Par exemple, les pilotes propriétaires nVidia installent leurs propres bibliothèques compatibles OpenGL en façade et qui pilotent directement leur matériel en coulisses. Intégrer cela en statique priverait ton logiciel de toute accélération matérielle.

[remi.a]

Merci de nouveau pour ces réponses.

J'ai commencé le portage. J'ai réussi à compiler l'application et la faire tourner.

J'ai donc choisi une solution VMWare 8.0 avec une Ferdora 14 64 bits. Le choix de la distribution a finalement été déterminé par un fait externe important. Il se trouve que mon application est un middleware dans le domaine de la synthese (du dépliage UV automatique). Hors les applications ténor de la synthèse supportent officiellement la Fedora 14, j'ai donc fait de même. Je vais bien sur faire de tests pour voir si des versions ultérieures de la Fedora fonctionnent, et voir aussi ce qui se passe sous une Ubuntu, une fois les problèmes réglés sur la Fedora 14.

Donc j'ai installé svn, un checkout, mis en place mon gestionnaire de compilation maison basé sur du code PHP. Installé (decompression de l archive, un configure, un make, mais pas de make install) à la main la wxWidget 2.9.2 (celle que j'utilise pour la version Windows et OSX). Avec yum, j'ai du installer aussi les version devel de GL, sinon le configure passait pas : mesa-libGL-devel-7.9.2, la GLU : lmesa-libGLU-devel-7.9.2, et la GLUT : freeGlut 2.6.0-5. Bien sur le gestionaire de package a installé pas mal de dépendences, je ne sais plus bien à quel moment, je sens bien que j'aurais du tout noter et que ça va me jouer des tours...

Après avoir testé le debogage à la main avec gdb, j'ai très vite laissé tomber et utilisé Eclipse, dont je suis très satisfait, du moins pour l'instant.

Finalement la majorité des problèmes rencontrés se manifestent lors du run liés à des différences de comportement au niveau de l'OpenGl. J'ai quand même réussi à éviter les spécifications systemes dans mon code pour l'instant. Les modifs fonctionnent donc sur les 2 systemes (win et linux, pas encore testé sur OSX).

- J'ai du spécifier explicitement le contexte OpenGL, notamment demandé d'activer spécifiquement le zbuffer. C'est fait par defaut sous win et OSX, pas sous Linux, du moins avec ces versions des libs.
- Certains parties du code OpenGL passaient sans faire d erreur, maintenant elles en génèrent sous Linux. J'ai du notamment modifier mes displays list. Mais ça finalement ça me parait normal, vu qu'apparement je faisais quelques trucs par réglo.
- Il reste que le display rate est atrocement lent. Mais ça je l'impute à la machine virtuelle.
- Il y a aussi des problèmes avec le clavier, mais ça aussi, il faut que je vois si ça ne vient pas de la VM.
- Sinon quelques petits trucs par ci par là, mais rien de bien méchant.

Je vais donc devoir faire un test grandeur nature, donc sans VM. Domage, car je trouve que bosser avec une VM, c'est vraiment très très pratique.

Voilà donc pour un premier petit rapport. Je reviendrai le completer plus tard.

Rémi

[LittleWhite]

Ouep, testé OpenGL dans la Virtual Machine, je ne suis pas ultra sur que ce soit une bonne chose ...
Je vous conseille, pour l'OpenGL, de faire un glGetErrro() après chaque fonction (au moins en debug) et de faire un test sur une vrai machine Linux, NVIDIA et une autre ATI, avec les pilotes proprio.