# ocaml/ocaml: the compiler, runtime and standard library behind every OCaml project

> The ocaml/ocaml repository is the core OCaml system itself, not a library you add to a project. This review covers what it ships, how the bytecode and native compilers differ, how to build it from source, and why OCaml 4.14 still exists next to 5.5.

**ocaml/ocaml** — The core OCaml system: compilers, runtime system, base libraries

- Repository: https://github.com/ocaml/ocaml
- Website: https://ocaml.org
- Stars: 6,586 · Forks: 1,411
- Language: OCaml
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ocaml-ocaml

## What ocaml/ocaml actually is, and who ends up needing it

This repository is the OCaml distribution: two compilers, the runtime system, the base libraries, the manual, the testsuite and the build system that ties them together. The README describes OCaml as a functional, statically-typed language from the ML family, with a module system extending Standard ML and a class-based object system. The top-level directory listing backs that up: bytecomp and asmcomp for the two back ends, runtime, stdlib, otherlibs, manual, testsuite, ocamltest.

Most people writing OCaml never touch this tree. They install a packaged compiler through their system package manager or the opam-based instructions linked from ocaml.org, and the repository only matters when something underneath breaks. The audience here is narrower: compiler contributors, people building OCaml for a platform with no ready package, toolchain maintainers who need to pin an exact version, and anyone debugging a runtime or standard library behaviour down to the source.

One consequence of that scope is that issues on this tracker are held to a high bar. The README asks bug reports to include a complete program, preferably small, that exhibits the unexpected behaviour, plus the machine configuration, and asks reporters to avoid adding LLM-generated content to the report.

## Bytecode, native code and the two compilers in one tree

The README is explicit that OCaml comprises two compilers, and the distinction drives most build decisions. The bytecode compiler produces code interpreted by a C program. It runs quickly, generates compact code with moderate memory requirements, and is portable across many 32-bit and 64-bit platforms. It can be used as a batch compiler producing standalone programs or as an interactive REPL.

The native compiler generates high-performance machine code. Compilation takes longer and the output is bigger, but the README states the generated programs deliver excellent performance while keeping the moderate memory requirements of the bytecode path. The platform table lists tier 1 targets as x86 64 on Linux, macOS, Windows and FreeBSD; ARM 64 on Linux and macOS; Power 64 on little-endian Linux with ABIv2; RISC-V 64 on Linux; and IBM Z (s390x) on Linux. Tier 2 covers NetBSD, OpenBSD, DragonFly, OmniOS and big-endian Power 64 Linux, maintained when possible.

The constraint worth internalising is stated with a warning marker in the README: from OCaml 5.0 onwards, native compilation is available only on 64-bit systems. Native compilation on 32-bit systems is gone, and the README says there are no plans to bring it back. If you target a 32-bit platform, you are on the bytecode compiler, and the tier table above does not apply to you.

## Building the compiler from source with configure and make

The README points installation at INSTALL.adoc for Unix, Linux, macOS, WSL and Cygwin, and at README.win32.adoc for native Microsoft Windows. The repository root carries the configure script, configure.ac, aclocal.m4 and a set of Makefile fragments, so the documented path is the usual configure-then-make sequence. The Makefile defines the default entry point as $(DEFAULT_BUILD_TARGET) and pulls in Makefile.common and Makefile.best_binaries, which is where the shared build logic lives.

The first step configures the tree. Run it from the repository root:

```bash
./configure
```

The script reads Makefile.config.in and Makefile.build_config.in to produce the generated configuration files. A successful run ends with a summary of the detected platform, the C compiler, and which optional components were found. If a dependency is missing, the summary names it rather than failing silently.

After configuration, build the default target. The Makefile also lists ARCHES as amd64 arm64 power s390x riscv, which reflects the native back ends present in the tree:

```bash
make
```

This is not a quick build. The native compiler is itself bootstrapped, and the repository keeps a boot directory for that purpose. If you only need the bytecode side, the Makefile fragments expose narrower targets, but the README does not enumerate them; read Makefile.common for the available names rather than guessing.

To get a usable interactive session after the build, the bytecode compiler doubles as the REPL. The README describes that standalone and interactive use as two modes of the same compiler.

## The 4.14 branch is not legacy cruft, it is a supported fallback

The most consequential fact in the README is the caution block at the top. OCaml 5.0.0, released in December 2022, rewrote the runtime system for shared-memory parallel programming using domains and added native support for concurrent programming through effect handlers. Because the garbage collector changed so much, OCaml 4.14, the final release in the 4.x series and originally released in March 2022, remains supported for the time being.

That support is real and current. The release list shows 4.14.4 published on 2026-06-15, alongside 5.5.0 on 2026-06-19 and 5.5.1 on 2026-09-04. A 4.x point release landing the same month as a 5.x release is not a museum piece; it is a maintained branch. The README also carries build status badges for trunk, 5.5, 5.4, 5.3 and 4.14, so all five lines get CI attention.

The practical reading: the 4.14 branch is where you stay if your dependencies have not caught up with the 5.x runtime, and the maintainers say so directly rather than leaving you to infer it. They also ask maintainers of existing codebases to evaluate OCaml 5.x and report performance degradations on the issue tracker. That request is a signal that migration is expected to be gradual and that regressions are treated as bugs worth filing, not as user error.

## Where ocaml/ocaml is the wrong thing to reach for

If your goal is to write an OCaml program, cloning this repository is the long way around. The README's availability section points to https://ocaml.org/docs/install.html, and the installation section defers to INSTALL.adoc and README.win32.adoc rather than giving a one-liner. Building the compiler from source takes minutes to tens of minutes depending on the machine, and it gives you a compiler you now have to keep patched yourself. A packaged compiler plus a package manager for libraries is the shorter path for application work.

The second case is platform mismatch. If you need native code on a 32-bit target, OCaml 5.x will not provide it, and the README states there are no plans to restore it. You are choosing between the bytecode compiler and staying on a 4.x line.

The third is the tier table. Tier 2 platforms are described as maintained when possible, which is honest but not a guarantee. If you are shipping on OpenBSD ARM 64 or big-endian Power 64 Linux, the README itself sets the expectation that native support there is best-effort. That is a deployment risk you should price in before committing.

Finally, the repository is large and its build has many moving parts: menhir-generated parsers, a bootstrap compiler, flexdll, and a testsuite driven by ocamltest. Patching it casually is not a weekend project.

## How this differs from a language distribution like GHC or a runtime like the JVM

The closest comparison is a language implementation that ships its own standard library and runtime as one artifact, the way GHC ships the Glasgow Haskell Compiler with base. The difference is in the concurrency story. GHC's runtime has offered lightweight green threads and a parallel garbage collector for years; OCaml's README frames domains and effect handlers as a full rewrite of the runtime arriving in 5.0, with 4.14 deliberately kept alive because the change was large. If you are choosing between the two for parallel workloads, OCaml's parallelism is the newer design, and the 4.14 fallback exists precisely because not everything has moved.

Against a managed runtime such as the JVM, the split is compilation model. The JVM compiles to bytecode for a virtual machine and relies on a JIT; OCaml ships two separate compilers, one producing bytecode interpreted by a C program and one producing native machine code, with the bytecode path doubling as the REPL. There is no JIT in the picture described by the README.

Against a systems language like Rust, the difference is what the repository contains. Rust's core repository is the compiler and standard library, and its package ecosystem is separate. ocaml/ocaml is the same shape, but the README explicitly notes that some libraries and tools are separately maintained, and the file listing includes otherlibs and an ocaml-variants.opam file, which is the seam where the core distribution ends and the wider ecosystem begins.

## Licence, maintenance and the cost of tracking trunk

The README's copyright section states that files marked Copyright INRIA are Copyright (C) 1996-2023 INRIA and distributed under the conditions in the LICENSE file. The Makefile header adds detail: it is distributed under the GNU Lesser General Public License version 2.1, with a special exception on linking described in LICENSE. That linking exception is the part that matters for commercial users, because it is what allows programs compiled against the runtime and standard library to be distributed under terms of your choosing. The repository metadata reports the licence as NOASSERTION, so read LICENSE directly rather than trusting an automated classifier. This is a description of what the files say, not legal advice.

Maintenance is not in question. The repository is not archived, and the last push was on 2026-09-21, one day before this writing. Releases are frequent: 5.5.1 on 2026-09-04, 5.5.0 on 2026-06-19, 4.14.4 on 2026-06-15. The README also points to release-info/calendar.md for a prospective calendar of future versions and release-info/News for descriptions of major changes in past ones, so the project publishes its own schedule.

The upgrade cost sits in the branch structure. Five branches are in CI, and the README asks existing codebases to evaluate 5.x and report degradations. Moving from 4.14 to 5.x means adopting a rewritten runtime, which is why the maintainers did not force it. If you pin a compiler for a product, budget for testing on both lines rather than assuming the newer one is drop-in.

## Conclusion

Adopt ocaml/ocaml if you are building OCaml tooling, pinning a compiler version, or need the runtime and standard library sources in one tree; if you only want to write OCaml programs, install a packaged compiler instead. Verify first which branch you need: 5.5 for domains and effect handlers, 4.14 if the codebase predates them. Check the tier table for your platform before assuming native code is available, since OCaml 5.x dropped 32-bit native compilation.

## FAQ

### What is OCaml used for?

The README describes OCaml as a functional, statically-typed language from the ML family with a module system extending Standard ML and a class-based object system, and OCaml 5.x adds shared-memory parallelism through domains and concurrency through effect handlers. The repository itself is the compiler, runtime and base libraries rather than an application.

### Is OCaml better than C++?

The README does not compare OCaml with C++. It does state that the native-code compiler generates high-performance machine code while retaining moderate memory requirements, and lists tier 1 targets including x86 64 on Linux, macOS, Windows and FreeBSD. Whether that is better than C++ depends on your workload, which the README does not address.

### Is OCaml better than Python?

The README makes no comparison with Python. It does describe two compilers: one generating bytecode interpreted by a C program, usable as a batch compiler or an interactive REPL, and one generating native machine code. That is the full extent of what the repository states about performance.

### How do I install OCaml?

The README's installation section points to INSTALL.adoc for Unix, Linux, macOS, WSL and Cygwin, and to README.win32.adoc for native Microsoft Windows. For a prebuilt distribution it links to https://ocaml.org/docs/install.html. Building from source uses the configure script and the Makefile at the repository root.

### How do I run OCaml code in a terminal?

The README states that the bytecode compiler can be used as a standalone batch-oriented compiler that produces standalone programs, or as an interactive REPL system. Building the tree with configure and make produces that compiler. The README does not document the exact REPL invocation command.

### How do I run OCaml on Windows?

The README directs native Microsoft Windows users to README.win32.adoc, and notes that INSTALL.adoc covers WSL and Cygwin. x86 64 Windows is listed as a tier 1 platform for native compilation, so native code generation is supported there under OCaml 5.x.

## Sources

- [Issues](https://github.com/ocaml/ocaml/issues)
- [ocaml/ocaml on GitHub](https://github.com/ocaml/ocaml)
- [Project website](https://ocaml.org)
- [README](https://github.com/ocaml/ocaml/blob/trunk/README.md)
- [Releases](https://github.com/ocaml/ocaml/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ocaml-ocaml