Where the Game's Own Modules Belong

A converted PS5 title is not just its main ELF and a folder of native libraries. The title may ship additional executable modules that contain engine, middleware, or game-specific code. AnyPS5 must preserve those modules as title-owned code while making their dependencies understandable to a Linux or Windows loader. This chapter follows that module lifecycle—from discovery and dependency analysis to converted output—and gives the reader a practical rule for telling app0/ title artifacts from libs/ AnyPS5 system libraries.

A title has more than one executable

The main executable is the entry point, but it is not necessarily the whole program. A title can import code from bundled ELF modules that it ships beside the main file. Those modules may call one another, export symbols for one another, or depend on the native system libraries that the relinker reconstructs. If AnyPS5 converted only the main executable, the host loader could reach the entry point and still fail when it tried to initialize the rest of the title.

The guest-module builder therefore looks for title-owned modules in the documented input locations: a singular module directory, a plural variant, or a prx directory. The names are not interchangeable decoration. The builder rejects a layout in which both sce_module and sce_modules are present, and it rejects a title with none of the accepted module locations unless module processing has been explicitly skipped. This early check prevents the relinker from silently treating an incomplete title package as a complete one.

Once a candidate directory is selected, the builder examines regular files for ELF magic and ignores artifacts that already carry AnyPS5's converted-module suffix. It can honor explicit exclusions, but an exclusion that names no real module is itself an error. It also compares the executable's needed-module names with the files it discovered. If a required module is not in the primary locations, the builder searches the relevant input tree for a unique matching ELF. Two different files with the same needed name are ambiguous; neither is chosen by guesswork.

That behavior reflects an ownership rule. The builder is not searching the whole computer for something that happens to have a familiar filename. It is resolving the title's own dependency graph within the package that the conversion command was given. A missing or ambiguous title module is therefore a packaging or identity failure, not an invitation to substitute an unrelated host library.

The builder also has to distinguish a module's file identity from its exported symbol identity. A filename or SONAME tells the dependency graph which image should be loaded. An exported symbol tells another image which address it may use after loading. These two namespaces can disagree without either one being malformed: a module can have a valid output filename but export a symbol that another guest image also provides. AnyPS5 checks both relationships because resolving one does not resolve the other.

That distinction is especially important when a module imports a symbol with a declared library name. The builder first finds possible guest providers by symbol name, then uses the declared library relationship and platform rules to decide whether a provider is allowed. If more than one provider survives that test, it reports an ambiguous import. The project is not trying to reproduce a host loader's accidental “first match” behavior; it is making the title's dependency assumptions explicit before writing files.