When developers release software, why do they usually provide precompiled binaries instead of LLVM IR along with a build script? Wouldn't a portable intermediate format let users run the same program on different CPU architectures? I thought one of the main benefits of high-level languages was being able to compile the same source for many platforms. What prevents LLVM-based distribution from being a more practical option?
5 Answers
LLVM IR is not a universal application format that users can simply launch. They would need a compatible LLVM toolchain, the correct system libraries, build configuration, and often additional development dependencies. That shifts the packaging and compatibility problem from the developer to every person installing the software, while also wasting time and disk space by having everyone compile the same code.
High-level languages make it easier to write mostly portable source code; they don't guarantee that one finished executable will run everywhere. The source can be compiled separately for each target, which is usually the practical compromise. Open-source projects often provide both prebuilt binaries for convenience and build instructions for people who need custom options or unsupported platforms.
Building from source can have real advantages, such as optimizing for a particular CPU, choosing optional features, or fitting a specific Linux distribution. Projects like Gentoo lean heavily on that model. However, most users would rather accept a small performance difference than troubleshoot compilers, dependencies, and configuration before they can use an application.
LLVM can help with CPU portability, but it doesn't solve operating-system differences. A Windows application still depends on Windows APIs, libraries, installers, file paths, graphics systems, and so on; compiling the same LLVM code on macOS won't automatically turn it into a Mac application. Supporting all those environments is a huge amount of work, and most users would rather download something that runs immediately.
The general idea already exists in systems such as Java bytecode and .NET's intermediate language. A runtime or virtual machine executes or recompiles the portable code for the local platform. This improves portability, but adds a runtime dependency and can involve trade-offs in startup time, memory use, performance, sandboxing, and access to platform-specific features.
Those runtimes work especially well when the application fits their abstractions. Desktop software that needs native operating-system integration often still needs platform-specific code or native libraries.
It also isn't common for users to need the same application on many CPU architectures. When that does matter, developers can ship separate builds, universal binaries, or use translation layers such as Rosetta.