The problem with unbuildable open source software
Jul 5th, 2025 - scudoIn the last couple of years, I've had a problem: some software is not available in binary form, or the binaries are too old to run on my system (this of course happens only on Linux, as Windows has amazing backwards compatibility most of the time); so I am forced to build it myself. Or I just want to do it anyway, just as a challenge.
These are a good part of the roadblocks I've encountered over time:
- The software doesn't list its dependencies.
- The software lists its dependencies, with the package name of a different distro or package manager (e.g.
Fedora's
-devel
vs Debian/apt's-dev
). - The dependencies changed name, or got absorbed into another package or library. (see older versions of
libjpeg-turbo
). - You need to build the dependencies first.
- The dependencies are not available or don't work (anymore) on your current platform.
- The software relies on libraries/packages that have since been deprecated and removed from package managers' repositories.
- The software has no instructions on how to build it, or they are hard to follow.
- The software's build chain relies on outdated technologies, or libraries, or packages, or old compilers, or specific versions of libraries.
- The build chain is available, but it doesn't work correctly, usually because it forgets to set the PATH variable, or some other variable. (hi, PS2SDK)
- The software includes no Makefile (or similar equivalent).
- The Makefile (or equivalent) is broken and/or requires specific old versions of libraries.
- The software was built with proprietary build tools, often old and outdated (like a huge chunk of old Windows programs that were built with Microsoft Visual C++ 2003).
- Compiling the software requires using proprietary old compilers and build tools (looking at you, Metrowerks CodeWarriors).
- The code references missing header files.
- The code calls some functions from custom libraries that are not included.
- The code lacks half of the things from its own .NET project that are fundamental for the software to build (hi, Ryujinx).
- The programmer(s) didn't really respect the GPL license and included only the code that they wrote and did not include the code that required them to license the program under the GPL license in the first place. (rare)
- The code references platform-specific OS syscalls that have a different name on the target platform (not Windows
syscalls on Linux, but the opposite; for example, there is no
mmap()
function in the Windows C standard library, you need MinGW's libraries to do that translation for you at compile time). - The software requires old proprietary blobs/binaries/libraries/header files to build.
- The software is written in a language that has no compiler (or modern compiler) for your target platform.
- Language version differences (e.g. Python 2.x vs Python 3.x).
- The software makes use of assembly language for another architecture (rare, and usually this rarely happens on x86, and cross-compilers + QEMU is a possibility, but a pain).
- Unknown/undefined data types (apparently, some compilers don't understand what a
u32
is if you don't tell it). - Custom, undefined data types.
- Reliance on undefined behiavor (see GTA: SA, but it's mostly unseen in modern software built with modern tools).
- Reliance on compilers being more lax in the past.
- Platform-specific quirks (e.g. PS2 and PS3 FPU being non-IEEE-754 compliant).
- The code makes assumptions about what platform it's supposed to be running on.
- You are trying to build a Java project with Maven or Gradle. Said enough.
- Hard to understand build failures - what is "Error 15" supposed to tell me?
- The compiled binary crashes (see OpenSSL on PowerPC).
- The compiled binary has weird glitches (very rare with modern software, mostly a matter of difference in behiavor between old and new compilers).
- You need to flash the software to a MCU/SoC/memory chip for which you need a proprietary flashing utility that is no longer available, or doesn't run well on modern OSs, or you need special flashing hardware (looking at you, Dallas TINI/DC85S350).
This isn't even a problem of reproducible builds; it's a matter of "is this software really free, or am I getting scammed?", and a matter of "why does their binary work, even if it's supposedly built in the same way, and mine doesn't"?