AnyPS5: relinking PS5 executables instead of emulating the console

Relinking, not emulating, and why that matters

The README states the approach in two clauses and it is worth parsing both. The project includes a relinker at `core/relinker` that converts an executable to the target system's native format, and implementations of system prx libraries at `core/libs/prx` suitable for dynamic linking. Then it says the important part: no emulation or separate runtime process.

That is a fundamentally different bet from the rest of the game-porting world. An emulator reproduces the hardware, which means writing a CPU interpreter, a memory model and a GPU driver, then accepting that the result runs at whatever speed your host allows. A relinker does none of that. It takes the compiled PS5 program, rewrites it into an ELF or PE binary your machine can load, and supplies the libraries the program expected to find on the console as ordinary shared objects.

The consequence is that a native game should behave like a native game: your graphics driver draws it, your scheduler runs it, your input stack sees it. The cost is that every PS5 system call has to be reimplemented by hand, one function at a time, and every one you miss stops the program. The repository topics say game-porting, spir-v, vulkan and ps5-tools, which is the honest shape of that workload.

One verified game, and what the badges measure

The status section carries two badges, one for libraries and one for shaders, plus a progress map, all hosted on a project page rather than as static images. The compatibility list lives at `docs/user/COMPATIBILITY.md`, and that is where a real assessment starts.

The README names exactly one verified game: Dreaming Sarah, a 2D platformer, described as running at a stable 60 fps on a GTX 1050 Ti with an i5-7500 at 3.4GHz. One game, and a 2D one. That number tells you the pipeline works end to end, since a 2D platformer still has to relink, load libraries, initialise graphics and pump input, but it tells you nothing about the 3D titles most people would want, where the shader path and the memory bandwidth story get interesting.

The failure policy is stated just as plainly. Unsupported or unexpected states strictly throw `std::runtime_error`, `what()` is printed to stderr, and the process terminates. No retry, no fallback, no partial rendering. For a porting tool this is the correct default, because silently continuing past an unimplemented function tends to produce a corrupted frame or a hang that costs more hours to diagnose than a clean abort costs seconds.

The shader recompiler and the SPIR-V validation claim

PS5 games ship shaders in Sony's proprietary format, so a native port has to translate them to something your driver understands. The compiler lives at `core/shader/recompiler/Recompiler.cpp` and the README says it successfully produces SPIR-V.

What makes that claim checkable is the next sentence: output is validated via Spirv-Tools in `3rdparty/SPIRV-Tools`, and only when built with `ANYPS5_ENABLE_SPIRV_TOOLS`. That is a conditional claim, stated as one, which is more than most projects offer. Worth noting that a release entry in `v0.1.0` is specifically a documentation correction to the SPIR-V validation claim, so the wording has been reviewed and adjusted since the first draft of the README.

Having SPIR-V output is what lets the Vulkan topic tag and the Vulkan path make sense together: a PS5 shader can be recompiled once at load time into SPIR-V, and then handed to a normal Vulkan driver. The expensive work is not the translation but getting the recompiler to agree with Sony's shading model on every construct a given title uses, which is why shader progress gets its own badge rather than being folded into library coverage.

The exception ABI fix that explains the architecture

One entry in the `v0.1.0` release notes is more revealing than the rest of that list combined: interpose the libstdc++ ABI on Linux so the project's own unwinder drives it.

That is a strange thing to have to do and it tells you something true about this kind of tool. PS5 binaries built with clang and the PS5 toolchain have their own assumptions about exception handling, and when you relink that code into a native Linux binary, two unwinders can end up competing: the one in the loaded program and the one in the system `libstdc++`. Whichever one wins decides whether a thrown exception unwinds cleanly or aborts the process.

Given that the stated failure mode is `std::runtime_error`, exception unwinding is not an edge case here, it is the error reporting mechanism. The fix makes the ported program's unwinder authoritative on Linux, which is what lets the clean-abort policy work at all. It is the kind of detail that never appears in a README and that any porting effort hits eventually.

Other entries in the same release show the same kind of work: a fix for `sscanf` `%x` signedness and an avoided substring copy, three of eight bitrotted AGC driver tests fixed and re-enabled, an implementation of `sceRandomGetRandomNumber`, and libSceRtc date and tick functions. Random numbers and a real-time clock are the sort of system service a game touches in its first second, so this is a project working outward from launch.

Building it means fighting the compiler, not the console

The Build section is unusually specific for a project at version 0.1.0, and the specificity is the point. The relinker uses only the C++20 standard library and should build with any conforming compiler. The `libc.prx` implementations in `core/libs/prx` do not: they contain compiler-specific code.

On Linux that means GCC works. On Windows the README states a hard requirement, MinGW-w64 GCC 15.2.0, specifically the `winlibs-gcc15` distribution with the `x86_64-ucrt-posix-seh` variant. That is a very narrow window. It is not a preference, it is a consequence of writing a C library that the ported binary links against directly, where the compiler's own data structures and calling conventions become part of the contract.

The project states that it targets maximum compiler portability and that support for additional compilers will be addressed after the first successful game launch. Naming the order of operations that plainly is useful: correctness first, then portability. The rest of the build story is CMake at the top level, `3rdparty/` for vendored dependencies pulled in through `.gitmodules`, and `tools/` alongside `core/` and `docs/`.

Unlike most C++ repositories there is no convenience build script in the tree, which tracks the state of the project: with one release and a bespoke toolchain there is not much yet for a wrapper to do.

Input, technical debt and the licence boundary

Input handling is the part of the port that touches the player directly. SDL-mapped controllers are supported, including analog sticks and triggers, and keyboard and mouse are configured through an `anyps5-input.ini` file with the format documented at `docs/user/INPUT_MAPPING.md`. That is a reasonable surface for a 2D platformer and a thin one for anything expecting a PlayStation camera, a touchpad or a second player with local multiplayer.

The repository also documents its own weaknesses rather than leaving a reader to find them. `docs/dev/TechnicalDebt.md` and `docs/dev/CONVENTIONS.md` are both linked from the README, and `docs/user/COMPATIBILITY.md` carries known issues alongside tested games. Projects that publish a technical debt file usually mean it, and this one has a compatibility list that names a single title.

The licence is GPL-2.0 only, and the disclaimer is unusually careful. The project states it is intended for interoperability, research, preservation and compatibility purposes, that it does not include, distribute or require copyrighted software, firmware, cryptographic keys or proprietary libraries, and that users are responsible for obtaining and using any binaries in accordance with applicable law and their licence terms.

That is the correct division of responsibility for this category of tool, and it is worth being explicit about what it means. The repository ships no PS5 firmware and no game data, which keeps it on the right side of the line and makes the GPL-2.0 licence uncontroversial for anyone who modifies it. What you do with your own legally obtained binaries is a separate question that this project deliberately does not answer for you. GPL-2.0 also means any derivative you distribute carries the same obligations, which matters if you fork the relinker rather than just using it.

Editorial conclusion

AnyPS5 is worth reading as an engineering artefact even if you never run a game through it, because the relinker-plus-prx-library approach is a clean answer to a problem most porting projects solve with an emulator. As a way to play retail titles, it is one tagged release old with a compatibility list whose verified entry is Dreaming Sarah, and the README does not claim otherwise. The build constraint is the sharpest practical fact: GCC on Linux, and MinGW-w64 GCC 15.2.0 from winlibs with the `x86_64-ucrt-posix-seh` variant on Windows, because the `libc.prx` implementations in `core/libs/prx` contain compiler-specific code. If you want to try it, start with the compatibility list rather than with the build, and read `docs/dev/TechnicalDebt.md`, which the README links as the project's own account of what it knows it has not finished.

Frequently asked questions

Official sources

1. boykopovar/AnyPS5 on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases