Deux builds sources : conversion seule, ou une pile hôte complète

Quand télécharger plutôt que compiler

Le zip officiel sur GitHub Releases est la paire prise en charge sur ce site : un relinker et les bibliothèques hôte correspondantes de la même étiquette. Compiler depuis les sources est facultatif. Utilisez-le quand vous changez le code, reproduisez un commit nommé, ou que le zip publié manque un morceau hôte que BUILD.md dit compilable.

Téléchargement : paire zip officielle · Chemin habituel : Releases officielles, puis installation.

Compiler depuis les sources lorsque

• Vous proposez un correctif et devez compiler l’arbre que vous avez modifié.
• Un rapport public nomme un commit ou une étiquette qui n’est pas la paire du zip publié.
• Vous avez besoin d’une bibliothèque hôte que le zip de version n’envoie pas pour votre OS — seulement si BUILD.md documente cette cible.

Les deux chemins de build documentés

Relinker seul : convertir l’ELF invité → PE ou ELF hôte

BUILD.md : ce mode construit l’outil de conversion sans initialiser les sous-modules ni configurer SDL, Vulkan, FFmpeg, FreeType ou le recompilateur de shaders. Il faut CMake, un compilateur C++20 et un outil de build. Python 3.9 ou plus récent active les tests Python. Le binaire est dans build-relinker/core/relinker/relinker (relinker.exe sous Windows avec Ninja).

cmake -S . -B build-relinker -G Ninja -DCMAKE_BUILD_TYPE=Release -DANYPS5_RELINKER_ONLY=ON -DBUILD_TESTING=ON
cmake --build build-relinker --parallel
ctest --test-dir build-relinker --output-on-failure

• La sortie est x86-64 : ELF Linux par défaut, PE Windows avec --windows, ou Mach-O avec --macos.
• Les titres convertis ont encore besoin de bibliothèques système compilées pour l’OS cible et d’un hôte x86-64 compatible. Le mode relinker seul ne construit pas ces bibliothèques.
• Les versions livrent des bibliothèques hôte pour Linux et Windows seulement.
• Utilisez un répertoire de build séparé si vous lancez ensuite le build complet.

Build complet : outils plus libs / runtime

Une pile exécutable commence par git submodule update --init --recursive. Avec BUILD_TESTING=OFF par défaut, cmake --build ne produit pas les bibliothèques corrigées. BUILD.md : chaque bibliothèque sous core/libs/prx est EXCLUDE_FROM_ALL, donc l’étape explicite --target libs est obligatoire. Les titres chargent les .prx corrigés depuis build/core/libs/libs.

git submodule update --init --recursive
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
cmake --build build --parallel
cmake --build build --target libs --parallel

• Exigences nommées sur le main actuel et à v0.1.3 : x86-64, Git, CMake 3.22.1 ou plus récent, Ninja, C++20. Ouvrez BUILD.md pour les paquets OS.
• Après un changement de bibliothèque, omettre --target libs teste les binaires précédents.
• USAGE.md : copiez build/core/libs/libs/*.prx dans le libs/ du titre. Utilisez des bibliothèques compilées pour l’OS cible.
• Self-build Windows : copiez aussi libgcc_s_seh-1.dll, libstdc++-6.dll et libwinpthread-1.dll de cette chaîne à côté des PRX corrigés. Le chargeur ne parcourt pas PATH ; des DLL manquantes peuvent apparaître comme erreur 126 même si le .prx est présent. Les zips de version les incluent déjà.

Bases de la reproductibilité

Les actifs officiels de version enregistrent une étiquette et un commit (web-release.json / release.json dans le job Pages). Si vous compilez, notez l’étiquette ou le commit de l’arbre construit. Un numéro de PR n’est pas une révision : les commits suivants et les résolutions de conflit changent l’arbre.

• Faites le checkout d’une étiquette (par exemple v0.1.3) ou d’un commit nommé, puis notez git rev-parse HEAD.
• N’omettez pas --target libs quand vous avez besoin d’une pile hôte exécutable.
• Gardez le relinker, les bibliothèques corrigées et (sous Windows) les trois DLL d’exécution MinGW de la même compilation.
• Ouvrez le BUILD.md de cet arbre. Le main actuel documente plus de chaînes Windows que le fichier de v0.1.3.

macOS et autres hôtes

README et BUILD.md : le build relinker seul tourne sur macOS, y compris Apple silicon, avec AppleClang des outils en ligne de commande Xcode. USAGE.md : --macos écrit un Mach-O x86-64, qui tourne sous Rosetta sur Apple silicon ; --to-rosetta abaisse les instructions que Rosetta n’a pas. Les titres convertis ont encore besoin de bibliothèques système pour l’OS cible. Les versions livrent ces bibliothèques pour Linux et Windows seulement. Une compilation relinker seul réussie, ou une conversion Mach-O, n’est pas un runtime de jeu macOS pris en charge et n’est pas Playable. L’inconnu reste inconnu.

Après le build

Un self-build n’est pas le zip officiel. Vous convertissez toujours un ELF propre et disposez app, libs/ et app0/ de la même façon. La différence est l’origine des deux fichiers hôte : votre répertoire de build au lieu de la paire d’actifs GitHub. Une fenêtre n’est pas Playable.

• Le mode relinker seul vous donne un convertisseur. Il ne remplace pas le zip des bibliothèques hôte.
• Un build complet a encore besoin de la disposition d’installation et du même ordre d’observation au premier lancement.
• L’erreur Windows 126 ou 193 après un self-build reste un problème de disposition ou de DLL manquante — voir le dépannage. Ne le traitez pas comme une étape de titre.

Un self-build n’est pas Playable

Réussir ctest ou produire app.exe / app.elf confirme ces étapes. Cela ne fait monter aucun titre. Citez l’étiquette ou le commit compilé sur la page du titre et dans Game bring-up. Cette page n’affirme pas que l’audio Linux est corrigé en v0.1.3. Game bring-up.

Téléchargement : paire zip officielle · Installation : disposition et ordre d’observation au premier lancement · Dépannage : 193, 126, limites de l’hôte

Sources d’origine

• BUILD.md sur le main actuel
• BUILD.md à l’étiquette v0.1.3
• USAGE.md (options de conversion, disposition runtime, --macos)
• README (relinker seul sur macOS, y compris Apple silicon)