# PSPSDK: the libraries and tools around the PSP toolchain > PSPSDK is the open source part of the PSPDEV toolchain: stub libraries for the console's operating system, a C runtime, a newlib glue layer, the libGU and libGUM graphics interfaces, and the command line tools that turn binaries into C sources, build PARAM.SFO files and pack EBOOT.PBP images. **pspdev/pspsdk** — An open-source SDK for PSP homebrew development. - Repository: https://github.com/pspdev/pspsdk - Website: https://pspdev.github.io - Stars: 1,197 · Forks: 186 - Language: C - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/pspdev-pspsdk ## The open source half of a cross-compilation toolchain PSPSDK is a collection of open source libraries and tools written for Sony's PlayStation Portable console, and it is part of the PSPDEV SDK, which is the larger set of tools the same organisation maintains. The division of labour is the standard one for a cross-compilation stack. The compiler, the assembler and the linker live in the PSPDEV toolchain, which is a separate repository and a separate prerequisite. What PSPSDK provides is everything that has to know what the console actually is: the interfaces to its operating system, the runtime that starts a program, the C library that the compiler's expectations require, and the utilities that turn your build output into something the console will run. That last part matters more than it sounds. A PSP program is not just an executable. There is the `PARAM.SFO` file that describes the application to the system, and there is the `EBOOT.PBP` container that packages it, and a homebrew developer has to produce both. PSPSDK ships the tools for that, and that is the difference between a project that builds and a project that boots. The project is the primary language is C, the default branch is `master`, and the last push was on 2026-10-13. There are no GitHub releases, and the homepage is `pspdev.github.io`, where the official source documentation is generated automatically from the `master` branch. The repository carries a `Doxyfile`, a `configure.ac` with an `m4` directory, a `Makefile.am`, a `bootstrap` script, a `build-and-install.sh`, a `Dockerfile`, a `doc/` directory and a `tools/` directory. One caveat appears in the notes and is worth repeating early, because it sets expectations: this is a BETA release of PSPSDK, and some of the features and tools described in the documentation may not be fully implemented. ## Stubs, a C runtime, and the glue newlib demands The library list describes the console from the outside in, and it is worth reading as a map of what a program on this hardware has to deal with. The first group is stub libraries and headers for interfacing with the PSP operating system, ranging from threading libraries, file input and output, the display driver and wifi networking. Stubs is the right word: they are the interface, not an implementation, and the real work happens on the console or in an emulator. The second group is the runtime. There is basic runtime support, `crt0`, for executables and for libraries, and there is a `libcglue` library for fulfilling the newlib system call requirements. The latter is the part that a C developer on a new platform always has to solve, because a hosted C library assumes an operating system underneath, and the console is not one of the ones newlib was written for. The glue layer is the shim that makes `printf` and `malloc` and file handles work on hardware that does not have a kernel underneath them in the usual sense. Alongside that there is support code for linking with the full Standard C Library provided with the PSPDEV toolchain, which is the difference between a program that can use the C library and one that can use the console's own libraries at the same time. The graphics side is two libraries. `libGU` provides an interface to the 2D and 3D hardware acceleration features of the PSP's Graphics Engine, and `libGUM` provides an interface for manipulating matrices for use in 3D software. A program that draws is using the console's own hardware through those interfaces, and the SDK supplies them. There is also a simple audio library for playing back PCM audio streams, and support for building static executables and PRX files, the relocatable modules the console can load. ## The tools that turn a build into something the console runs The tools are the part of the SDK that every homebrew project has to use, and the list is a good indication of what a launchable artefact involves. `bin2c`, `bin2o` and `bin2s` convert binary files into C source, object files and assembler source files respectively. That is the mechanism for embedding a resource, a font, a sound or a texture into a program, and having all three output formats means the same data can be embedded at compile time, at link time or as assembly. `mksfo` and `mksfoex` create PARAM.SFO files, which is the metadata container the system reads to know an application's name, its icon and its parameters. `pack-pbp` and `unpack-pbp` add and remove files from an EBOOT.PBP container, so a signed or packaged image can be assembled and taken apart. `psp-config` is the one that is used the most, and it locates the PSPDEV tools and libraries, which is how a build finds the toolchain regardless of where it is installed. The remaining three are about the executable format. `psp-prxgen` converts specially made ELFs into PRX files, `psp-build-exports` creates export tables, and `psp-fixup-imports` fixes up import tables after linking, removing unused functions from the executable. That last one is a size optimisation that has to happen after the link step, and it is a detail that only exists because the format allows unused imports to be pruned. For the everyday case there is a library for Make, `build.mak`, which provides an easy way to build simple programs and libraries, and the README points to any PSPSDK sample program for how it is used. Documentation for the libraries is provided as well, in the `doc/` directory of both the source and the binary distributions. ## Building it is autotools, in four commands The build is a standard GNU autotools project, and the README walks through it without shortcuts. The requirements are a toolchain and a few build tools: the PSPDEV Toolchain, GNU Make, a Git client, GNU autoconf and automake, and the Zlib development libraries and headers. Doxygen and Graphviz are listed separately, with the note that they are not required to build PSPSDK but are used to build the documentation. The source comes from the Git repository: ```bash git clone https://github.com/pspdev/pspsdk.git ``` Then the configure script and its support files are generated, which needs autoconf and automake installed: ```bash ./bootstrap ``` And the build and install follow: ```bash ./configure make make doxygen-doc make install ``` The note in the README says that if you have not installed Doxygen or do not want to build the library documentation, you can skip the `make doxygen-doc` command, and the tip says you can use the `build-and-install.sh` script for convenience. That script is also what the container build runs. Two continuous integration workflows are visible in the badges, one for compilation and one for Docker, so the build is exercised in both shapes. The `Dockerfile` in the repository root is a two stage build. The first stage takes a base image, copies the source, installs the build packages with `apk add build-base autoconf automake zlib-dev bash git`, and runs `/src/build-and-install.sh`. The second stage is `alpine:latest`, sets `PSpdev` to `/usr/local/pspdev` and puts its `bin` directory on the path, copies the installed tree out of the first stage, and then installs a long list of additional packages with `apk add`, among them `acl`, `sudo`, `fakeroot`, `gpgme-dev`, `libarchive-tools`, `doxygen`, `texinfo`, `flex` and `gettext-dev`. The image is therefore a full development environment rather than a minimal build container. ## Where it installs, and the one template limitation to design around Two notes in the README are the kind that save a day, and both are about the relationship between PSPSDK and the rest of the toolchain. The first is the install location. By default PSPSDK installs into the directory where the PSPDEV toolchain is installed. If you decide to install PSPSDK somewhere else, you must define a PSPSDK environment variable that points to the alternate directory, and the `psp-config` build utility looks for PSPSDK in the location specified by that variable first, or uses its own location to determine where PSPSDK is installed. So the installation is not independent of the toolchain, and there is exactly one supported way to move it. That is a sensible design for a stack where the compiler and the libraries have to agree about targets and include paths, and it is a constraint for a build system that expects each component to be separately installable. The second is the Make templates. The Makefile templates provided by the sample code are designed for building a single executable or a library, but not both, and the README is explicit that if you plan to use the templates to build both libraries and executables you have to structure your project so that each library and executable is built in a separate directory. That is a real constraint rather than a documentation gap, because the templates are the easy path into the SDK, and a project that discovers the limitation after writing a hundred lines of Makefile has to reorganise its source tree. The alternative is to write your own rules on top of `psp-config` and the compiler, which is more work and gives more control, and the `tools/` directory in the repository has the pieces a custom build needs. The other resource worth knowing about is the `doc/` directory, which is shipped in both the source and the binary distributions, and the community documentation the README links for the hardware itself, the Allegrex processor and the VFPU, the unofficial PSP docs and the detailed Yet Another PSP Documentation. ## Where PSPSDK is the wrong tool Three limits matter, and one of them is about the licence rather than the code. The first is the hardware. PSPSDK is for the PlayStation Portable, so a project on any other platform gets nothing from it, and a project that wants a homebrew for a different console needs a different SDK entirely, since the interfaces, the executable format and the packaging tools are all console specific. The second is the beta status. The README says plainly that some of the features and tools described may not be fully implemented, and this is an SDK where a missing implementation is not a missing convenience but a missing capability, because the interface to the display driver or to the network is the thing your program is written against. A team shipping a project on top of it should expect to implement the missing parts themselves. The third is the licence split, and it is a small paragraph with a real consequence. PSPSDK is distributed under a BSD-compatible licence, with the exception of the files located in `tools/PrxEncrypter`, which are subject to the terms of the GNU General Public License version 3. So the SDK is permissively licensed except for one directory, and a project that links or ships that tool has to satisfy the GPL for it. The `LICENSE` files in the repository are the authoritative text, and the GitHub metadata does not classify the repository under a standard licence, which is consistent with a mixed-licence tree. The alternative for somebody who wants to understand the console rather than build for it is the community documentation the README links, which covers the CPU, the VFPU and the hardware interfaces in much more depth than an SDK header set does, and it needs no toolchain at all. The difference in approach is that PSPSDK is a build system and a set of interfaces to write against, and the documentation is a description to read, and a project that only needs the understanding should take the second one and skip the first. ## Conclusion PSPSDK fits a developer writing homebrew for the PlayStation Portable who wants the console's interfaces as headers and libraries rather than as reverse engineered knowledge, and who is prepared to install a cross toolchain first. It is the wrong choice for a project that only wants to understand the hardware, because the community documentation linked from the README covers that without a build, and it is the wrong choice for a team expecting a stable, finished platform, since the SDK is described as a beta release where some features and tools may not be fully implemented. Before you build, note the two practical constraints in the README: the build templates produce either an executable or a library but not both, so a project with both has to be split into separate directories, and the install location defaults to the toolchain directory, with the PSPSDK environment variable as the only override. ## FAQ ### How do I build the PSP SDK from source? Clone the repository, run `./bootstrap` to create the configure script, then `./configure`, `make`, `make doxygen-doc` and `make install`, or use the build-and-install.sh script for convenience. You need the PSPDEV Toolchain, GNU Make, a Git client, autoconf and automake, and the Zlib development headers, and the Doxygen documentation step can be skipped. ### Which tools does PSPSDK provide? bin2c, bin2o and bin2s convert binary files into C source, object files and assembler source, mksfo and mksfoex create PARAM.SFO files, pack-pbp and unpack-pbp handle EBOOT.PBP containers, psp-config locates the tools and libraries, psp-prxgen turns ELFs into PRX files, psp-build-exports creates export tables and psp-fixup-imports strips unused imports after linking. ### Where does PSPSDK install, and how do I change that? By default into the directory where the PSPDEV toolchain is installed. To install elsewhere, define a PSPSDK environment variable pointing at the alternate directory, and the psp-config build utility looks there first when locating PSPSDK. ### What licence is PSPSDK under? A BSD-compatible licence, with one exception: the files in the tools/PrxEncrypter directory are subject to the GNU General Public License version 3. The LICENSE files in the repository are the authoritative text. ## Sources - [Issues](https://github.com/pspdev/pspsdk/issues) - [Project website](https://pspdev.github.io) - [pspdev/pspsdk on GitHub](https://github.com/pspdev/pspsdk) - [README](https://github.com/pspdev/pspsdk/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pspdev-pspsdk