Création d’un package pour recalbox : ZELDA SOLARUS
-
mince j'ai oublié de faire les add avant de comiter... je suis vraiment vraiment désolé , je repousse ça demain matin..
-
salut, normalement c'est bon les fichiers ont été ajoutés
-
j'ai tenté une autre compilation de openal à partir ce source là: http://kcat.strangesoft.net/openal-releases/openal-soft-1.16.0.tar.bz2 et là j'ai un message d'erreur que je n'avais pas avec la 1.15 :
libopenal.so.1.16.0: référence indéfinie vers « Mix_Neon »
Mix_Neon étant un truc de PulseAudio visiblement..: https://github.com/lynxis/pulseaudio/blob/master/src/pulsecore/mix_neon.c mais j'ai beau avoir mis "depends on BR2_PACKAGE_PULSEAUDIO" dans le Config.in de openal, j'ai le même message d'erreur.
-
Bonjour @Hellrider, retroboy a apparemment travaillé sur ton github hier
-
Salut, Un grand merci à toi retroboy pour le merge request ^^ Par contre j'avoue que je n'ai pas tout compris à ce que tu as fait. Sans vouloir abuser de ton temps, est ce que tu pourrais m'expliquer à quoi correspond concrètement l'option : OPENAL_INSTALL_STAGING = YES (je suppose que ça "force " le compilateur à assembler tout les fichiers de compilation dans un seul et même répertoire autre que celui des sources, et que ce répertoire est accessible pour tout les packages (dans ce cas pourquoi ne pas mettre cette option tout le temps?).. et j'ai cherché sur le web ce qu'est le stage directory, mais bien que cela semble une notion élémentaire, je ne trouve rien de précis à part cette définition : "The data staging area sits between the data source(s) and the data target(s)") Pourquoi le selected simplifie l'installation par rapport à depends on ? enfin , c'est là que je vois mes lacunes en script shell,car même si je comprends que ce que tu as rajouté dans le zeldasolarusdx.mk sert à copier les fichiers dans les bon répertoires, je n'en saisi pas tout les détails syntaxique et je ne comprends pas pourquoi on ne copie pas les headers? (de la même façon que je ne saisi pas le **define ZELDASOLARUSDX_RPI_FIXUP.in ** même si je l'ai "recopié" en m'inspirant d'un autre package ) Par contre tu as remplacé Lua_5_1 par LuaJit, et la compilation de celui-ci pose problème : erreur_compile_luajit Edit: @Acris oui, j'ai vu ^^ j'étais en train de rédiger ce post
-
Héhé, tu as bien résumé les questions que je me posai aussi lol.
-
Coucou, Petit extrait de la notice de buildroot
Buildroot output is stored in a single directory, output/. This directory contains several subdirectories: images/ where all the images (kernel image, bootloader and root filesystem images) are stored. These are the files you need to put on your target system. build/ where all the components are built (this includes tools needed by Buildroot on the host and packages compiled for the target). This directory contains one subdirectory for each of these components. staging/ which contains a hierarchy similar to a root filesystem hierarchy. This directory contains the headers and libraries of the cross-compilation toolchain and all the userspace packages selected for the target. However, this directory is not intended to be the root filesystem for the target: it contains a lot of development files, unstripped binaries and libraries that make it far too big for an embedded system. These development files are used to compile libraries and applications for the target that depend on other libraries. target/ which contains almost the complete root filesystem for the target: everything needed is present except the device files in /dev/ (Buildroot can’t create them because Buildroot doesn’t run as root and doesn’t want to run as root). Also, it doesn’t have the correct permissions (e.g. setuid for the busybox binary). Therefore, this directory should not be used on your target. Instead, you should use one of the images built in the images/ directory. If you need an extracted image of the root filesystem for booting over NFS, then use the tarball image generated in images/ and extract it as root. Compared to staging/, target/ contains only the files and libraries needed to run the selected target applications: the development files (headers, etc.) are not present, the binaries are stripped. host/ contains the installation of tools compiled for the host that are needed for the proper execution of Buildroot, including the cross-compilation toolchain.Donc ce qu'il faut retenir : - build contient les sources + les builds. Donc la même chose que si vous téléchargiez des sources et que vous faisiez le make a la main. Les fichiers sont juste placés dans dés répertoires correspondants au nom du package. - target contient l'arboréscence des fichiers qui seront copié sur le système. Donc on vire tout ce qui n'est pas nécessaire, comme par exemple les headers, la documentation... - et celui qui nous intéresse la, c'est staging, qui contient tout ce qui va être nécessaire aux autres packages pour compiler, dans une arborescence système. Donc par exemple, une lib (un .so) sera installé avec les hearders dans staging, pour permettre la compilation des dépendances, et le .so seulement sera copié dans target (pas besoin de compiler sur la recalbox)
Pourquoi le selected simplifie l’installation par rapport à depends on ?
Le selected permet de selectionner automatiquement le package cible (openal dans ce cas par exemple) lors de la selection du package a installer (zelda). Si tu laisse depends, il sera impossible de selectionner zelda tant que tu ne sera pas allé séléctionné a la main openal.
-
Merci beaucoup pour tes explications !! je pense que je vais vraiment finir par prendre le temps de lire la doc de builtroot .. le temps à passer à le faire au début sera récupéré par la suite, c'est certain !!! mais du coup, pourquoi l'option Staging n'est pas l'option par défaut? au premier abord, c'est l'option à utiliser systématiquement non?
-
Non seulement pour les libs. Par exemple pour un libretro, tu a juste a les copier dans target, car aucun autre package va utiliser les fichiers produits pour sa propre compilation
-
ok, je comprends. Merci pour la clarification ^^ Bon faut que je compile Lua maintenant ! Par contre Lua 5.1 n'était pas la bonne lib par rapport à luajit? (je dis ça car il me semble que lua5.1 s'était compilée si je ne dit pas de bêtise le premier coup.
-
par contre pour info, je vais renommer les paquet en solarusengine car là nous ne compilons que le moteur... https://github.com/christopho/solarus le jeu se trouvant ici: https://github.com/christopho/zsdx donc il faudra encore que je crée un dernier paquet pour compiler les data du jeu en lui même et les copier à la main dans un sous dossier dans le répertoire de solarus engine (un truc dans le genre en tout cas..)
-
Courage Hellrider
-
Héhé oui accroche toi
-
héhé, ça compile, ça compile ^^ mais vu l'heure je vais laisser tourner.. je verrai le résultat au réveil
en tout cas j'ai poussé les modifications avec l'ajout du package contenant les datas du jeu et en modifiant le nom de l'engine . (pour les data, j'ai fait le .mk de façon qu'il les installe dans le répertoire de solarus ^^ en tout cas si je ne me suis pas trompé..lol) -
Salut, Alors c'est bon le moteur graphique Solarus a compilé !! et visiblement ça s'est bien passé (on a bien généré un fichier pour du ARM ^^):
~/recalbox-buildroot/output/target/usr/games/solarus$ file solarus_run solarus_run: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped ~/recalbox-buildroot/output/target/usr/games/solarus$ file libsolarus.so libsolarus.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped
par contre la je bloque sur un problème de syntaxe dans le mk des data du jeu. En gros au moment de a compilation des datas, je veux les copier dans un sous répertoire dans le répertoire du moteur solarus.. j'ai tenté pas mal de syntaxes mais rien de passe, comme par exemple file(MAKE_DIRECTORY path ) :
ZSDXDIRECTORY=$(TARGET_DIR)/usr/games/solarus/zsdx file(MAKE_DIRECTORY $(ZSDXDIRECTORY)) me renvoie ce message: >>> zeldasolarusdx 1.10.1 Installing to target ZSDXDIRECTORY=/home/ana/recalbox-buildroot/output/target/usr/games/solarus/zsdx file(MAKE_DIRECTORY ) /bin/bash: -c: ligne 0: erreur de syntaxe près du symbole inattendu « MAKE_DIRECTORY » /bin/bash: -c: ligne 0: `file(MAKE_DIRECTORY )'
là j'en suis là:
MKDIR_P = mkdir -p ZSDXDIRECTORY=$(TARGET_DIR)/usr/games/solarus/zsdx $(MKDIR_P) $(ZSDXDIRECTORY) $(INSTALL) -D $(@D)/* \ $(TARGET_DIR)/usr/games/solarus/zsdx
comme vous pouvais le deviner j'essaie de créer le répertoire zsdx dans le répertoire de solarus (le moteur donc) et ensuite je veux installer les fichiers compilé dans ce répertoire.. hors à le compilateur me jette en me disant que mkdir est une commande introuvable.. Je dois libérer la place car comme vous le voyer dans le nom du user, c'est le PC de ma femme ^^ des idées ?
-
voilà le message que j'ai si j'utilise install -D : dans mon zeldasolarusdx.mk
Just copy the Data in a subdirectory of solaris define ZELDASOLARUSDX_INSTALL_TARGET_CMDS $(INSTALL) -D $(@D)/* \ $(TARGET_DIR)/usr/games/solarus/zsdx endef
et voilà le message d'erreur: /usr/bin/install -D /home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.10.1/* /home/franck/recalbox-buildroot/output/target/usr/games/solarus/zsdx /usr/bin/install: la cible «/home/franck/recalbox-buildroot/output/target/usr/games/solarus/zsdx» n'est pas un répertoire make: *** [/home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.10.1/.stamp_target_installed] Erreur 1 ok la cible n'existe pas encore mais install -D est sensé la créer non?
-
bon bin avec ça :
Just copy the Data in a subdirectory of solaris define ZELDASOLARUSDX_INSTALL_TARGET_CMDS mkdir -p $(TARGET_DIR)/usr/games/solarus/zsdx $(INSTALL) -D $(@D)/. \ $(TARGET_DIR)/usr/games/solarus/zsdx endef
ça fonctionne ^^ , y a plus qu'à tester et faire en sorte de pouvoir le lancer depuis emulestation
-
Sa devient bon tous sa, sa donne envie. Merci pour le taff mec.
-
Oué on attends le résultat avec impatience
-
bon pas beaucoup de temps ce soir.. j'ai copié le répertoire games et tout son contenu sur le raspi... mais il se passe ceci quand j'execute solarus (zdsdx contenant les datas du jeu et se trouvant dans solarus): # ./solarus_run zsdx/ ./solarus_run: error while loading shared libraries: libSDL2_image-2.0.so.0: cannot open shared object file: No such file or directory bon du coup j'hésite à refaire une installe complète de ma carte SD.. ou copier à la main les différentes lib manquantes depuis le répertoire target.. mais là j'en ai une qui me réclame la place devant son pc... la suite demain soir
retroboy, si tu as une piste pour que je l'exécute "rapidement" depuis emulestation je suis preneur.. vu le message d'erreur, le fichier est bien compilé je pense .. (la je l'ai lancé en ssh .. du coup je ne suis pas sur qu'il se serait exécuté sur la télé si j'avais bien eu toutes les libs...) Bonne fin de soirée à tous et merci pour les encouragements
