# libressl/portable: Building LibreSSL Beyond OpenBSD

> libressl/portable builds the OpenBSD-developed LibreSSL fork on Linux, macOS, Windows, Android, Solaris and other systems. It covers much of the OpenSSL 1.1 API, but it is neither ABI compatible with OpenSSL nor compatible with the OpenSSL 3 API.

**libressl/portable** — LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.

- Repository: https://github.com/libressl/portable
- Website: https://www.libressl.org
- Stars: 1,500 · Forks: 290
- Language: C
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/libressl-portable

## What libressl/portable actually provides

libressl/portable is the portable build scaffold and compatibility layer around LibreSSL, which began as a fork of OpenSSL 1.0.1g and is developed by OpenBSD. Its stated goal is to modernize that codebase, improve security and apply OpenBSD development practices. The repository is therefore more than a collection of application headers. It contains the build system, compatibility code, command-line applications, tests, CMake package files and platform support needed to build LibreSSL outside OpenBSD.

The intended users are developers and system builders who want an OpenBSD-origin TLS implementation on Linux, macOS, Windows, Android, Solaris, FreeBSD, NetBSD, HP-UX, AIX, Emscripten and supported Windows toolchains. The README lists Linux, FreeBSD, NetBSD, HP-UX, Solaris, Mac OS X, AIX and Emscripten as known build environments. It also identifies Microsoft Windows, Wine, MinGW-w64, Cygwin and Visual Studio as supported Windows environments. This is a broad portability statement, but the README gives version boundaries for several operating systems, so platform support should not be interpreted as support for every possible environment.

## The OpenSSL compatibility boundary in libressl/portable

LibreSSL implements much of the OpenSSL 1.1 API. It does not currently implement the OpenSSL 3 API, which is the central limitation for teams evaluating it as an OpenSSL replacement. The README says incompatibilities between LibreSSL and OpenSSL are unavoidable because the projects pursue different goals and priorities. It also states that important incompatibilities may be addressed only when doing so does not conflict with LibreSSL's stated goals of simplicity, security and sanity.

Binary compatibility is absent by design. LibreSSL is not ABI compatible with any OpenSSL release, and it is not necessarily ABI compatible with earlier LibreSSL releases. Programs must be relinked when moving to LibreSSL, much as they must be when moving between major OpenSSL versions. Installed library version numbers increase when API or ABI changes occur. A familiar source-level API therefore does not guarantee that an existing OpenSSL-linked program can replace its library without changes.

The repository includes `FindLibreSSL.cmake` and package templates such as `LibreSSLConfig.cmake.in`. These can help CMake consumers locate an installed LibreSSL package, but they do not remove the need to compile and test application code against the selected release. Source compatibility claims should also be checked against the particular APIs an application calls.

## Choosing configure or CMake for a first build

A Git checkout or GitHub source tarball must be prepared before building. The README requires a bash shell, including on Windows, and lists `automake`, `autoconf`, `git`, `libtool` and `perl` as required packages. Running the repository's generation script creates the files needed by the configure build. If those prerequisites cannot be met, the README advises downloading an official release distribution instead.

The configure path is useful when the project needs the established Unix-style build flow and installation rules. The CMake path provides a separate route and also supports Ninja and Visual Studio generators. CMake options can control installation rules, applications, tests, shared-library output and assembly. Applications are required to run tests, while tests are documented as available only in static builds. These defaults mean that changing `LIBRESSL_APPS` or `LIBRESSL_TESTS` affects more than build time. A missing application may prevent the test stage from running, and enabling tests in an unsuitable library configuration may require revisiting the build type.

The README does not provide a packaged installer command. Official release tarballs are hosted under the OpenBSD FTP mirror hierarchy, which is the documented route for users who do not need to prepare a development checkout.

## Preparing and compiling a Git checkout

After obtaining the repository, the first documented operation prepares the autotools files. The README warns that the build will fail if this preparation is skipped. The following commands show the complete configure, test and install path documented for that build system.

```bash
./autogen.sh
./configure
make check
make install
```

`./autogen.sh` prepares the source tree. `./configure` creates the build configuration and exposes additional options through its help interface. `make check` runs the built-in unit tests, while `make install` installs the result. The README says `DESTDIR` can be set to install into an alternate location. That variable is useful for staged installation, but the README does not give a complete cross-compilation procedure or a package-manager recipe.

This is a source build rather than a setup for a standalone TLS client. The repository includes `apps/`, but the README does not document a first-use command for connecting to a TLS server or issuing an HTTP request. For an application developer, the first real use is to build LibreSSL, run `make check`, install it, relink the application and exercise its TLS code through the application's existing tests.

## Using CMake for Linux, Ninja or Visual Studio

The CMake workflow starts from the same prepared source tree. It is the documented route for a separate build directory and supports generators that are not based on a single Make utility. The standard sequence is short.

```bash
mkdir build
cd build
cmake ..
make
make test
```

After `cmake ..` configures the source tree, `make` builds it and `make test` runs the configured tests. A reader should expect this route to produce the same LibreSSL targets and tests described by the CMake configuration, rather than treating `cmake` as an installer command.

For Ninja, the README gives an equivalent build directory and generator selection.

```bash
mkdir build-ninja
cd build-ninja
cmake -G"Ninja" ..
ninja
ninja test
```

On Windows with Visual Studio, the documented generator is selected during configuration.

```bash
mkdir build-vs2022
cd build-vs2022
cmake -G"Visual Studio 17 2022" ..
```

The README does not document a post-configuration command for building or installing the Visual Studio project. The available CMake options are `LIBRESSL_SKIP_INSTALL`, `LIBRESSL_APPS`, `LIBRESSL_TESTS`, `BUILD_SHARED_LIBS` and `ENABLE_ASM`. Their defaults are respectively `OFF`, `ON`, `ON`, `OFF` and `ON`. Because `LIBRESSL_TESTS` is enabled by default but documented for static builds, a team should confirm its chosen library configuration before treating test execution as an acceptance check.

## Release handling and maintenance status

The repository is not archived, and its last push was on 2026-10-15. The release list includes v4.3.3 and v4.2.2 on 2026-10-05, along with v4.4.0rc1. The README explains that major releases are usually made around the end of April and October, sometimes following a release candidate.

LibreSSL portable uses `N.N.P[rcR]` versioning. Patch releases are described as ABI and API compatible and are used for bug and security fixes. Major releases advance in increments of 0.1 with carry, including the sequence 4.8, 4.9 and 5.0. Release candidates append `rcR`. This scheme distinguishes stable patch releases from candidates, but it does not remove application migration work across major versions.

The repository identifies `libressl@openbsd.org` for ordinary bugs, its GitHub issue tracker for public reports, and `libressl-security@openbsd.org` for severe vulnerabilities or bugs requiring coordination with OpenSSL. The GitHub repository mirrors the portable build framework, while the OpenBSD FTP mirror carries official release tarballs. Upgrade planning should account for source preparation, relinking, tests and any application changes required by the release-specific API boundary.

## License implications and adoption limits

GitHub's repository classification lists the license as `Other` and points readers to the `LICENSE` file for the custom terms. The README does not reproduce those terms, so this review cannot state a standard permissive or copyleft grant or provide legal interpretation. Anyone preparing a distribution should read `LICENSE` directly and check how it applies to the LibreSSL source, bundled files and the application being linked.

The clearest technical limitation is compatibility. LibreSSL cannot be dropped into a deployment by replacing an OpenSSL shared object. It is not ABI compatible with OpenSSL, does not currently support the OpenSSL 3 API, and may differ from earlier LibreSSL versions at the API or ABI level. The practical consequence is a recompile and relink cycle followed by application testing. Code that depends on OpenSSL behavior outside the covered 1.1 surface may also need changes.

A real alternative is OpenSSL itself, the upstream project from which LibreSSL's historical fork began. OpenSSL follows its own release path and defines the interfaces in its current versions. LibreSSL follows OpenBSD goals and deliberately rejects some additions that lack a clear reason. libressl/portable is the more relevant choice when the requirement is to build OpenBSD's LibreSSL outside OpenBSD. It is the wrong choice when an OpenSSL 3 interface or OpenSSL binary compatibility is mandatory.

## Conclusion

Developers should consider libressl/portable when they need LibreSSL on a non-OpenBSD system and can accept its compatibility boundary. Projects that require OpenSSL 3, binary compatibility with OpenSSL, or a drop-in library replacement should choose a different target library. The first adoption check is to compile the application against the intended LibreSSL release, run its test suite, and relink every binary rather than reuse OpenSSL objects.

## FAQ

### Can libressl/portable be built on Linux?

Yes. The README lists Linux as a supported operating system and recommends kernel 3.17 or later. It documents both configure and CMake build paths.

### Does LibreSSL support the OpenSSL 3 API?

No. The README states that LibreSSL provides much of the OpenSSL 1.1 API but does not currently support the OpenSSL 3 API.

### Can I replace OpenSSL by changing a linked library at runtime?

No. The README says LibreSSL is not ABI compatible with any OpenSSL release. Programs must be relinked against LibreSSL, just as they must be when moving between major OpenSSL versions.

## Sources

- [Issues](https://github.com/libressl/portable/issues)
- [libressl/portable on GitHub](https://github.com/libressl/portable)
- [Project website](https://www.libressl.org)
- [README](https://github.com/libressl/portable/blob/master/README.md)
- [Releases](https://github.com/libressl/portable/releases)

---

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