Release pour linux

Bonjour,

je ne sais pas si je suis vraiment dans la bonne section, mais j'aurais besoin d'un coup de main pour faire une release de mon jeu MineDeeper (codé en c++) sous linux. Je ne connais pas vraiment comment linux fonctionne et je n'arrive pas à obtenir mon exécutable.
Voici en gros mes problèmes:
-Le fichier ne trouve pas mes .so (car j'utilise la SFML)
-Il ne s'ouvre pas lorsque je double clique dessus (je dois le faire par la console)
-Le fichier n'a pas d'icône (pas de fichier ressource sous linux à ce que je vois, c'est supposé marcher avec un fichier desktop, mais j'y arrive pas)

J'ai compilé mon jeu sous codeblocks, je ne suis pas habitué à le faire en console, mais je peux apprendre...

Merci de votre aide,
Sytten

Bonjour,

je serai plus que surpris (comprendre : il est impossible) que la SFML ne fournisse pas un téléchargement pour linux avec les .so entre autre.
Ensuite, Linux c'est différent de Windows, la ligne de commande tu devras surement y passer pour une partie.
Pour l'exécution via double-click il faut peut-être simplement définir le fichier comme exécutable.

Salut,

J'ai mes .so (je les ai buils moi-même), je n'arrive juste pas à faire qu'il regarde dans le même dossier pour les trouver. J'ai déjà mis mon fichier comme étant exécutable...

Merci

Bonjour,

Dans un cas de compilation des bibliothèque à la main, il faut tenter un "make install". Sinon, il faut spécifier le LD_LIBRARY_PATH :

Citation:

---

LD_LIBRARY_PATH=chemin_ou_sont_les_bibliothèques ./monProgramme

---

Oui même avec un make install (qui installe le tout dans usr/local/lib et include) ça pas l'air de fonctionner. Ce que j'aimerais c'est que n'importe qui qui download mon jeu puisse y jouer sans devoir passer par le terminal et spécifier où sont les .so...

Bonjour,

Comment le loader linux trouve-t-il les bibliothèques ?
Il cherche successivement dans

1. la liste de répertoires (séparateur : ) donnée par la variable d'environnement LD_LIBRARY_PATH.
   Si la variable n'existe pas ou si la bibliothèque n'est pas trouvée alors :
2. la liste des bibliothèques configurées via ldconfig (cf la man page)
   si la bibliothèque n'est pas référencée alors :
3. dans le répertoire /lib puis /usr/lib (lib64 ou lib32 aussi si l'OS est 64bit ou s'il y a une installation multilib)
   Si elle n'est toujours pas trouvée alors il y a une erreur de chargement

Le mécanisme est un peu plus compliqué car on peut préciser lors de l'édition des liens un chemin codé en dur (cf rpath) ... je n'en parlerai pas ici.

Si tu installes des bibliothèques en-dessous de /usr/local alors il faut être certain de passer par ldconfig pour les référencer, ou utiliser LD_LIBRARY_PATH comme indiqué par LittleWhite.

Ensuite si tu désires proposer ton application sur Linux il va falloir créer des packages (.deb pour debian et cie, .rpm pour les distros comme fedora, ...) qui vont lister les dépendances. Par exemple ton jeu dépend de SFML, alors l'utilisateur final qui veut installer ton jeu via un package et qui ne dispose pas des bibliothèques nécessaires se verra installer tout ce qui lui manque. Le package contiendra non seulement l'installation de tes binaires et data mais aussi des commandes qui vont créer des raccourcis sur le desktop ou des entrées dans un menu game, ou ...
Si tu crées également des bibliothèques, il va falloir t'assurer soit que tu les installes où le loader les trouve facilement ou utiliser ldconfig pour les référencer.

Bonjour,

Merci de cette réponse claire et précise.
Pour spécifier la variable LD_LIBRARY_PATH, cela peut-il est fait dans un fichier .desktop? Celui-ci peut-il être à côté de l'exécutable afin que le joueur puisse ouvrir le jeu simplement?
Mon but est d'éviter de devoir créer ces packages (comme sous windows je ne propose pas d'installeur...) si c'est possible (mais je comprend que non jusqu'à maintenant). Je vais certainement fournir les .so avec mon jeu, comme je fourni les dll sous windows...

Merci de votre patience,
Sytten

C'est une mauvaise idée de distribuer des so dont tu n'es pas propriétaire puis de les placer dans des endroits non conventionnels, c'est un habitude issue du monde windows qui est à proscrire.

L'idéal pour un utilisateur de base est réellement le clic sur un lien vers un package adapté à sa distribution. Si son environnement est bien configuré le bon outil sera lancé, un mot de passe pour acquérir les droits admin sera demandé, les packages dépendant seront downloadés dans la bonne version et installés, les icônes crées, etc.
C'est clair que cela demande du travail, mais c'est la contre-partie de simplifier la vie à l'utilisateur final :)

Alors évidemment, si tu cherches à être complet, ça peut faire exploser les différentes versions que tu proposeras :

• un .deb pour linux 32bit
• un .deb pour linux 64bit
• un .rpm pour linux 32bit
• un .rpm pour linux 64bit
• un .apk pour android
• un .tgz pour slackware ou les linux non deb/rpm en 32 bits ou les users avancés
• un .tgz pour slackware ou les linux non deb/rpm en 64 bits ou les users avancés
• un .msi/.exe pour windows 32bit
• un .msi/.exe pour windows 64bit
• ....

Utiliser LD_LIBRARY_PATH peut être dangereux et n'est en général pas recommandé en release (quoique certains produits l'utilisent sans se soucier plus que ça des problèmes).
Si tu te reposes sur la méthode préconisée par les ditros tu auras moins de problèmes du côtés des users qui sont prompt à classifier un programme qui ne fonctionne pas comme «grosse m....» et à ne plus jamais l'utiliser voir à le déconseiller ...
Les tests dans ton cas sont hyper importants, heureusement maintenant avec les VM ça les simplifie :)

Dans l'éventualité où tu préfères proposer une installation du type «on met tout dans un répertoire du home dir du user, on utilise LD_LIBRARY_PATH, on bidouille un .deskop, ...» c'est faisable et la doc doit exister pour ça aussi.

Très intéressant totalement ce que je cherchais comme réponse.
Je vais regarder pour faire quelques packages. Sûrement des .tgz, puisque je ne crois pas que beaucoup de personnes du grand public (comprendre personne ayant des connaissances minimales en info) vont joué à mon jeu et encore moins sous linux :aie:

Je vais regarder cela de plus près, je laisse le sujet ouvert et je vous reviens là dessus le plus tôt possible :ccool:

Il manque un paquet binaire .exe sans installateur (pour pouvoir mettre sur clé USB, ou lorsque l'on a aucun droit :aie:)
Les paquets 32/64 binaires, on peut les regrouper (style warsow / Heroes of Newerth) qui inclut un petit script shell qui suivant le uname (le kernel :aie:) il sélectionne le binaire 32 ou 64 lors du lancement du jeu.

Oui pas faux :)
Mais pour une version portable USB autant lier statiquement et on évacue le problèmes des so/dll à distribuer :aie:

Salut,

Citation:

---

Envoyé par Sytten

Très intéressant totalement ce que je cherchais comme réponse.
Je vais regarder pour faire quelques packages. Sûrement des .tgz, puisque je ne crois pas que beaucoup de personnes du grand public (comprendre personne ayant des connaissances minimales en info) vont joué à mon jeu et encore moins sous linux :aie:

---

Au contraire...

Je commencerais sans doute plutôt par les .deb/.rpm pour que les utilisateurs des distributions utilisant ces systèmes puissent en profiter.

Des distributions comme ubuntu (.deb) sont suffisamment "user friendly" pour intéresser des gens "pas forcément habituées" mais qui veulent simplement "jeter windows".

Tu auras donc très certainement un plus large publique en visant cette distribution particulière qu'en visant un slackware ou (pire) un LFS :D

De toutes façons, débutant ou confirmé, tout le monde a des raisons de vouloir jouer un peu ;)

Une note a propos de cette histoire d'installation propre sous Linux:

Personnellement je trouve que le cas des jeux est a part et pose un serieux probleme au developeur sous linux. Le developeur a besoin d'etre certain qu'une version du jeu ait un comportement aussi fidele que possible qu'avec d'autres copies du jeu (dans les limites du hardware et des configurations evidement). Mais le fait de laisser le systeme fournir les bibliotheques sur lesquelles repose le jeu ajoute une enorme variable incontrollable. Cela n'est pas un probleme pour tout ce qui est des systemes de base evidemment, ca ne peut etre qu'un avantage. En revanche c'est un gros souci par exemple si on utilise une bibliotheque graphique (type Ogre) dans une version specifique qu'on a compile sois meme ou encore on utilise une version qui est compatible niveau interface avec celle du system mais la version du systeme a une legere difference de comportement notable uniquement dans votre utilisation de cette bibliotheque.
On pourra dire ce qu'on veut, la bibliotheque, dans ce genre de cas, ne vas pas etre mise a jour rapidement, et cela aura un impacte directe sur l'experience du joueur qui est plus facile a briser que l'experience de l'utilisateur d'un outil (qui devrait etre aussi poussee mais on est assez tolerant avec un outil, on l'est beaucoup moins avec ce qui n'est plus du travail).

Donc, personellement, je trouve que suivre ces recommandations est a prendre avec des pincettes. Verifiez bien que ca ne posera pas trop de problemes par la suite. Ca depends des jeux, ca depends de si on a besoin de faire des updates tres souvent, ca depends de plein de choses. Mais il ne faudrait pas suivre les guidelines aveuglement juste par dogmatisme.

Je comprends bien en quoi c'est plus efficace pour linux, et je comprends aussi en quoi toute une categorie d'applications (certains types de jeux) sont problematiques avec ces guidelines, et je doute qu'il y a beaucoup de gens du monde linuxien qui comprennent bien ces situations. Peu de linuxien comprennent l'importance d'avoir un jeu organise en boite noire et c'est franchement lassant.


Bref.

Bonjour tout le monde,

Je suis quasiment sûr que l'utilisation des RPATH peuvent être utile.

J'ai fait un micro projet (Pièce jointe 119025) avec CMake qui utilise les chemins relatifs.

Vu que la sfml (du moins la version 2) utilise CMake, je pense que tu peux t'inspirer en grande partie de ces scripts.

N'hésite pas si tu rencontres des problèmes.

Citation:

---

Envoyé par darkman19320

Bonjour tout le monde,

Je suis quasiment sûr que l'utilisation des RPATH peuvent être utile.

J'ai fait un micro projet (Pièce jointe 119025) avec CMake qui utilise les chemins relatifs.

Vu que la sfml (du moins la version 2) utilise CMake, je pense que tu peux t'inspirer en grande partie de ces scripts.

N'hésite pas si tu rencontres des problèmes.

---

Cela permettra sans doute de permettre de compiler le jeu (ou l'application) en fonction des bibliothèques présentes, voir de fournir à celui qui compile la liste des dépendances manquantes (et des versions de celles-ci).

Cependant, cela ne résout qu'une partie du problème:

Qu'il soit "confirmé" ou "débutant" (et surement encore d'avantage s'il est débutant), peu de gens me semblent disposer à passer "un temps bête" à installer les différentes dépendances "juste" dans l'espoir de compiler un jeu.

Et cela me semble d'autant plus vrai si les dépendances en questions impliquent de compiler une version qui n'est pas encore intégrée au système de paquets :aie:

@Klaim > Je ne peux qu'être d'accord en substance avec ce que tu dis.

il faut cependant garder en tête qu'il est beaucoup plus du ressort du développeur de se "débrouiller" pour "coller" à la réalité vécue par l'utilisateur que ce n'est du ressort de l'utilisateur de s'arranger pour disposer de ce qu'il faut pour utiliser une application donnée ;)

De plus, à part si on tourne sous Debian ou sous une autre distribution dont la priorité est la stabilité, il me semble malgré tout que les autres distributions tentent de mettre les différents paquets à jour dans des délais relativement raisonnables ;)

Citation:

---

Envoyé par koala01

il faut cependant garder en tête qu'il est beaucoup plus du ressort du développeur de se "débrouiller" pour "coller" à la réalité vécue par l'utilisateur que ce n'est du ressort de l'utilisateur de s'arranger pour disposer de ce qu'il faut pour utiliser une application donnée ;)

---

Sauf dans le cas de jeux, parceque linux est totalement construit pour etre un outil flexible, pas une boite fermee ou tu fais tourner des trucs dedans (comme Windows...). Autrement dit, il y a un conflit de principe dans les deux aproches, qui sont naturelles donc.

Citation:

---

De plus, à part si on tourne sous Debian ou sous une autre distribution dont la priorité est la stabilité, il me semble malgré tout que les autres distributions tentent de mettre les différents paquets à jour dans des délais relativement raisonnables ;)

---

Ce que je "critique" ce ne sont pas les updates de ce qui est dans le systeme, mais les updates du jeu lui meme. Les mises a jours de paquet ne se font pas a la meme vitesse que ce qui arrive sur certains jeux qui sont fait pour le long terme et on des update quasimment tous les jours. Auquel cas il est preferable d'avoir un auto-updater, ce qui amene a contourner le systeme de base pour pouvoir ecrire regulierement la ou le jeu est installe, donc il ne faut pas l'installer la ou ca serait indique normalement.

Tout ca pour dire que, clairement si on peut faire comme indique par linux, faut le suivre. Mais pas aveuglement, parceque ya certains cas ou ca colle pas du tout a l'application, et ce qui compte c'est les applications bien plus que les OS.

Mais je pense qu'on s'est compris. :ccool:

@koala: Non le but est simplement de fournir l'exécutable avec la bibliothèque dynamique sur une autre machine et que le joueur joue à son jeux favori.

A partir du RPATH, on peut faire différents package (deb, rpm, sh ou ce que l'on veut) sans à avoir à se soucier des dépendances (on les fournis dans le paquet).

Alors va pour des packages .deb en premier...

Si je peux fournir mes dépendances avec mon jeu ça serait mieux à mon avis puisque je ne serais pas dépendant de l'évolution de la SFML (même si je reste à jour la plupart du temps...)

Ensuite, dois-je garder mes dépendances dans le même fichier que celui du jeu ou les déplacer dans un fichier du genre /usr/local/lib et include? Parce que si je fais cela, ils peuvent entrer en conflit avec des dépendances de la SFML déjà présentes sur l'ordinateur...

Merci

Si vous faites un .deb, en théorie, c'est dans un fichier de configuration du .deb que vous indiquez les dépendances et c'est au gestionnaire de paquet de les résoudre. Il n'y a pas de conflit, car si la bibliothèque est installée, c'est ok, sinon, il l'installe comme une dépendance.