Zwei Quellbuilds: nur konvertieren oder ein voller Host-Stack

Wann herunterladen statt bauen

Das offizielle Zip auf GitHub Releases ist das unterstützte Paar dieser Seite: ein Relinker und die passenden Host-Bibliotheken desselben Tags. Bauen aus dem Quellcode ist optional. Nutzen Sie es, wenn Sie den Code ändern, einen genannten Commit nachbauen oder dem veröffentlichten Zip ein Host-Teil fehlt, den BUILD.md als kompilierbar beschreibt.

Download: offizielles Zip-Paar · Alltagspfad: offizielle Releases, dann Einrichtung.

Aus dem Quellcode bauen, wenn

• Sie einen Patch beitragen und den bearbeiteten Baum kompilieren müssen.
• Ein öffentlicher Bericht einen Commit oder Tag nennt, der nicht das veröffentlichte Zip-Paar ist.
• Sie eine Host-Bibliothek brauchen, die das Release-Zip für Ihr OS nicht mitliefert — nur wenn BUILD.md dieses Target dokumentiert.

Die zwei dokumentierten Build-Pfade

Nur Relinker: Gast-ELF → Host-PE oder -ELF

BUILD.md: dieser Modus baut das Konvertierwerkzeug ohne Submodule und ohne SDL, Vulkan, FFmpeg, FreeType oder den Shader-Recompiler. Er braucht CMake, einen C++20-Compiler und ein Build-Werkzeug. Python 3.9 oder neuer aktiviert die Python-Regressionstests. Die Binärdatei landet in build-relinker/core/relinker/relinker (relinker.exe unter Windows mit 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

• Ausgabe ist x86-64: Linux-ELF standardmäßig, Windows-PE mit --windows oder Mach-O mit --macos.
• Konvertierte Titel brauchen weiterhin Systembibliotheken für das Ziel-OS und einen kompatiblen x86-64-Host. Relinker-only baut diese Bibliotheken nicht.
• Releases liefern Host-Bibliotheken nur für Linux und Windows.
• Nutzen Sie ein getrenntes Build-Verzeichnis, wenn Sie später den vollen Build ausführen.

Voller Build: Werkzeuge plus Libs / Runtime

Ein lauffähiger Host-Stack beginnt mit git submodule update --init --recursive. Mit dem Standard BUILD_TESTING=OFF erzeugt cmake --build die gepatchten Bibliotheken nicht. BUILD.md: jede Bibliothek unter core/libs/prx ist EXCLUDE_FROM_ALL, daher ist der explizite Schritt --target libs nötig. Titel laden die gepatchten .prx-Dateien aus 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

• Anforderungen auf aktuellem main und bei v0.1.3: x86-64, Git, CMake 3.22.1 oder neuer, Ninja, C++20. OS-Pakete stehen in BUILD.md.
• Nach einer Bibliotheksänderung testen Sie ohne --target libs die vorherigen Binärdateien.
• USAGE.md: kopieren Sie build/core/libs/libs/*.prx ins libs/ des Titels. Nutzen Sie Bibliotheken für das Ziel-OS.
• Windows-Self-Build: kopieren Sie außerdem libgcc_s_seh-1.dll, libstdc++-6.dll und libwinpthread-1.dll dieser Toolchain neben die gepatchten PRX-Dateien. Der Loader durchsucht PATH nicht; fehlende DLLs können als Fehler 126 erscheinen, obwohl die .prx vorhanden ist. Release-Zips enthalten sie bereits.

Grundlagen der Reproduzierbarkeit

Offizielle Release-Assets halten Tag und Commit fest (web-release.json / release.json im Pages-Job). Wenn Sie kompilieren, notieren Sie Tag oder Commit des gebauten Baums. Eine PR-Nummer ist keine Revision: spätere Commits und Konfliktauflösungen ändern den Baum.

• Checken Sie einen Tag aus (zum Beispiel v0.1.3) oder einen genannten Commit und halten Sie git rev-parse HEAD fest.
• Überspringen Sie --target libs nicht, wenn Sie einen lauffähigen Host-Stack brauchen.
• Behalten Sie Relinker, gepatchte Bibliotheken und (unter Windows) die drei MinGW-Laufzeit-DLLs aus derselben Kompilierung.
• Öffnen Sie das BUILD.md dieses Baums. Aktuelles main dokumentiert mehr Windows-Toolchains als die Datei von v0.1.3.

macOS und andere Hosts

README und BUILD.md: der Relinker-only-Build läuft unter macOS, einschließlich Apple Silicon, mit AppleClang aus den Xcode-Kommandozeilentools. USAGE.md: --macos schreibt x86-64-Mach-O, das unter Rosetta auf Apple Silicon läuft; --to-rosetta senkt Anweisungen, die Rosetta fehlt. Konvertierte Titel brauchen weiterhin Systembibliotheken für das Ziel-OS. Releases liefern diese Bibliotheken nur für Linux und Windows. Ein bestandener Relinker-only-Compile oder eine Mach-O-Konvertierung ist keine unterstützte macOS-Spielruntime und nicht Playable. Unbekannt bleibt unbekannt.

Nach dem Build

Ein Self-Build ist nicht das offizielle Zip. Sie konvertieren weiterhin eine saubere ELF und legen app, libs/ und app0/ gleich an. Der Unterschied ist die Herkunft der zwei Host-Dateien: Ihr Build-Verzeichnis statt des GitHub-Asset-Paars. Ein Fenster ist nicht Playable.

• Relinker-only liefert einen Konverter. Es ersetzt das Host-Bibliotheken-Zip nicht.
• Ein voller Build braucht weiterhin das Einrichtungs-Layout und dieselbe Beobachtungsreihenfolge beim ersten Start.
• Windows 126 oder 193 nach einem Self-Build bleibt ein Layout- oder fehlendes-DLL-Problem — siehe Fehlerbehebung. Nicht als Titelstufe werten.

Ein Self-Build ist nicht Playable

Bestehendes ctest oder erzeugtes app.exe / app.elf bestätigt diese Schritte. Es wertet keinen Titel auf. Nennen Sie Tag oder Commit, den Sie gebaut haben, auf der Titelseite und in Game bring-up. Diese Seite behauptet nicht, Linux-Audio sei in v0.1.3 behoben. Game bring-up.

Download: offizielles Zip-Paar · Einrichtung: Layout und Beobachtungsreihenfolge beim ersten Start · Fehlerbehebung: 193, 126, Host-Grenzen

Originalquellen

• BUILD.md auf aktuellem main
• BUILD.md am Tag v0.1.3
• USAGE.md (Konvertieroptionen, Runtime-Layout, --macos)
• README (Relinker-only unter macOS, einschließlich Apple Silicon)