Création d’un package pour recalbox : ZELDA SOLARUS
-
Merci pour les encouragement ^^ Bon SDL2_IMAGE, c'est fait et SDL2_TTF aussi
mais j'ai encore un message d'erreur lié à openal alors que je l'ai déjà compilé..CMake Error at /home/franck/recalbox-buildroot/output/host/usr/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find OpenAL (missing: OPENAL_LIBRARY OPENAL_INCLUDE_DIR) Call Stack (most recent call first): /home/franck/recalbox-buildroot/output/host/usr/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE) /home/franck/recalbox-buildroot/output/host/usr/share/cmake-3.1/Modules/FindOpenAL.cmake:101 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) cmake/AddDependencies.cmake:12 (find_package) CMakeLists.txt:6 (include) -- Configuring incomplete, errors occurred! See also "/home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.4.1/CMakeFiles/CMakeOutput.log". See also "/home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.4.1/CMakeFiles/CMakeError.log". make: *** [/home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.4.1/.stamp_configured] Erreur 1
voila openal.mk :
################################################################################ # # openal # ################################################################################ OPENAL_VERSION = 1.15.1 OPENAL_SOURCE = openal-soft-$(OPENAL_VERSION).tar.gz OPENAL_SITE = https://github.com/JogAmp/openal-soft/archive OPENAL_LICENCE = GPL OPENAL_DEPENDENCIES = define OPENAL_RPI_FIXUP.in $(SED) 's|/opt/vc/include|$(STAGING_DIR)/usr/include|g' $(@D)/CMakeLists.txt $(SED) 's|/opt/vc/lib|$(STAGING_DIR)/usr/lib|g' $(@D)/CMakeLists.txt endef OPENAL_PRE_CONFIGURE_HOOKS += OPENAL_RPI_FIXUP $(eval $(cmake-package))
la deuxième partie j'avoue que je n'en suis pas du tout certain.. (j'ai copié(immité) ce qu'il y avait dans emulation-station.. bon par contre la suite se fera à partir de lundi car je sens que je vais pas avoir le temps de m'y coller du we...
-
Salut il y a quoi dans ces logs ? See also « /home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.4.1/CMakeFiles/CMakeOutput.log ». See also « /home/franck/recalbox-buildroot/output/build/zeldasolarusdx-1.4.1/CMakeFiles/CMakeError.log ».
-
je les ai vite consulté mais rien d'évident ne m'a sauté aux yeux.... là il faut que je recrée un projet chez moi pour tenter d'avance dans le we..
-
faudrais que tu fork recalbox, ou au moins que tu crée un repo github, que j'ai accès a tes scripts de compilation en live
en plus ca pourra t'aider a prendre en main git et github, qui vont t’être nécessaires pour crée la pull request -
avec plaisir, je connais un peu Git pour l'utiliser en local avec moi même sur gitlab.. mais je n'ai jamais forké de projet ni utilisé Github, c'est l'occasion me lancer ^^
-
Cool ça se poursuit.
-
Ca marche alors j'attends de tes nouvelles et on continue quand tu as fait ton fork de recalbox-buildroot
-
Super merci, le fork est fait depuis ce we (BlessedHellRider sur GitHub, c'est moi) ^^ aujourd'hui j'ai été dans un jus total, j'ai à peine eu le temps de cloner le dépôt en local... Demain je "mets à jour" mon dépôt en local avec les nouveaux packages et je push ça ^^
-
Salut, voilà j'ai pu commiter mes fichiers ^^ https://github.com/BlessedHellRider/recalbox-buildroot/commits/recalbox-rpi2 sinon j'ai découvert ce matin que quand je fais make menuconfig, Zelda n'est plus sélectionnable.. je suppose que c'est normal car j'ai ajouté des dépendances mais je trouve ça bizarre car je pensais toutes les avoir bien déclarées.. sinon j'ai toujours le même message d'erreur quand je fais un make zeldasolarusdx:
CMake Error at /home/franck/recalbox-buildroot/output/host/usr/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find OpenAL (missing: OPENAL_LIBRARY OPENAL_INCLUDE_DIR)
-
Il manque ton package zelda dans ton repo
-
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.
