Dos builds de fuente: solo convertir, o una pila anfitriona completa

Cuándo descargar en vez de compilar

El zip oficial en GitHub Releases es el par admitido en este sitio: un relinker y las bibliotecas anfitrionas coincidentes de la misma etiqueta. Compilar desde el código es opcional. Úsalo cuando cambias el código, reproduces un commit nombrado, o el zip publicado no trae un trozo anfitrión que BUILD.md dice que puedes compilar.

Descarga: par zip oficial · Camino habitual: Releases oficiales y luego instalación.

Compila desde el código cuando

• Contribuyes un parche y necesitas compilar el árbol que editaste.
• Un informe público nombra un commit o etiqueta que no es el par del zip publicado.
• Necesitas una biblioteca anfitriona que el zip de versión no envía para tu SO: solo si BUILD.md documenta ese destino.

Los dos caminos de build documentados

Solo relinker: convertir ELF invitado → PE o ELF anfitrión

BUILD.md: este modo construye la herramienta de conversión sin inicializar submódulos ni configurar SDL, Vulkan, FFmpeg, FreeType o el recompilador de shaders. Necesita CMake, un compilador C++20 y una herramienta de build. Python 3.9 o más reciente activa las pruebas de Python. El binario queda en build-relinker/core/relinker/relinker (relinker.exe en Windows con 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 salida es x86-64: ELF de Linux por defecto, PE de Windows con --windows, o Mach-O con --macos.
• Los títulos convertidos siguen necesitando bibliotecas de sistema compiladas para el SO de destino y un anfitrión x86-64 compatible. El modo solo-relinker no construye esas bibliotecas.
• Las versiones envían bibliotecas anfitrionas solo para Linux y Windows.
• Usa un directorio de build aparte si luego ejecutas el build completo.

Build completo: herramientas más libs / runtime

Una pila ejecutable empieza con git submodule update --init --recursive. Con BUILD_TESTING=OFF por defecto, cmake --build no produce las bibliotecas parcheadas. BUILD.md: cada biblioteca bajo core/libs/prx está EXCLUDE_FROM_ALL, así que el paso explícito --target libs es obligatorio. Los títulos cargan los .prx parcheados desde 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

• Requisitos nombrados en el main actual y en v0.1.3: x86-64, Git, CMake 3.22.1 o más reciente, Ninja, C++20. Abre BUILD.md para los paquetes del SO.
• Tras un cambio de biblioteca, omitir --target libs prueba los binarios anteriores.
• USAGE.md: copia build/core/libs/libs/*.prx al libs/ del título. Usa bibliotecas compiladas para el SO de destino.
• Self-build de Windows: copia también libgcc_s_seh-1.dll, libstdc++-6.dll y libwinpthread-1.dll de esa cadena junto a los PRX parcheados. El cargador no busca en PATH; las DLL que falten pueden aparecer como error 126 aunque el .prx esté. Los zips de versión ya las incluyen.

Básicos de reproducibilidad

Los activos oficiales de versión registran una etiqueta y un commit (web-release.json / release.json en el trabajo Pages). Si compilas, anota la etiqueta o el commit del árbol que construiste. Un número de PR no es una revisión: los commits posteriores y las resoluciones de conflicto cambian el árbol.

• Haz checkout de una etiqueta (por ejemplo v0.1.3) o de un commit nombrado y anota git rev-parse HEAD.
• No omitas --target libs cuando necesites una pila anfitriona ejecutable.
• Mantén el relinker, las bibliotecas parcheadas y (en Windows) las tres DLL de runtime MinGW de la misma compilación.
• Abre el BUILD.md de ese árbol. El main actual documenta más cadenas de Windows que el archivo de v0.1.3.

macOS y otros anfitriones

README y BUILD.md: el build solo-relinker corre en macOS, incluido Apple silicon, con AppleClang de las herramientas de línea de comandos de Xcode. USAGE.md: --macos escribe Mach-O x86-64, que corre bajo Rosetta en Apple silicon; --to-rosetta baja instrucciones que Rosetta no tiene. Los títulos convertidos siguen necesitando bibliotecas de sistema para el SO de destino. Las versiones envían esas bibliotecas solo para Linux y Windows. Una compilación solo-relinker correcta, o una conversión Mach-O, no es un runtime de juego macOS admitido y no es Playable. Lo desconocido sigue desconocido.

Después del build

Un self-build no es el zip oficial. Sigues convirtiendo un ELF limpio y organizando app, libs/ y app0/ igual. La diferencia es de dónde salen los dos archivos anfitriones: tu directorio de build en vez del par de activos de GitHub. Una ventana no es Playable.

• El modo solo-relinker te da un conversor. No sustituye el zip de bibliotecas anfitrionas.
• Un build completo sigue necesitando el esquema de instalación y el mismo orden de observación en el primer arranque.
• El 126 o 193 de Windows tras un self-build sigue siendo un problema de esquema o de DLL que falta: ve a la solución de problemas. No lo trates como etapa de título.

Un self-build no es Playable

Pasar ctest o producir app.exe / app.elf confirma esos pasos. No sube de etapa ningún título. Cita la etiqueta o el commit que compilaste en la página del título y en Game bring-up. Esta página no afirma que el audio de Linux esté corregido en v0.1.3. Game bring-up.

Descarga: par zip oficial · Instalación: esquema y orden de observación en el primer arranque · Solución de problemas: 193, 126, límites del anfitrión

Fuentes originales

• BUILD.md en el main actual
• BUILD.md en la etiqueta v0.1.3
• USAGE.md (opciones de conversión, esquema de runtime, --macos)
• README (solo-relinker en macOS, incluido Apple silicon)