Building BoringSSL

Build Prerequisites

Perl 5.6.1 or later is required. On Windows, Active State Perl has been reported to work, as has MSYS Perl. Strawberry Perl also works but it adds GCC to PATH, which can confuse some build tools when identifying the compiler (removing C:\Strawberry\c\bin from PATH should resolve any problems). If Perl is not found by CMake, it may be configured explicitly by setting PERL_EXECUTABLE.

On Windows you currently must use Ninja to build; on other platforms, it is not required, but recommended, because it makes builds faster.

If you need to build Ninja from source, then a recent version of Python is required (Python 2.7.5 works).

On Windows only, Yasm is required. If not found by CMake, it may be configured explicitly by setting CMAKE_ASM_NASM_COMPILER.

A C compiler is required. On Windows, MSVC 12 (Visual Studio 2013) or later with Platform SDK 8.1 or later are supported. Recent versions of GCC (4.8+) and Clang should work on non-Windows platforms, and maybe on Windows too.

Go is required. If not found by CMake, the go executable may be configured explicitly by setting GO_EXECUTABLE.

If you change crypto/chacha/chacha_vec.c, you will need the arm-linux-gnueabihf-gcc compiler:

If you want to build as a shared library, pass -DBUILD_SHARED_LIBS=1. On Windows, where functions need to be tagged with dllimport when coming from a shared library, define BORINGSSL_SHARED_LIBRARY in any code which #includes the BoringSSL headers.

In order to serve environments where code-size is important as well as those where performance is the overriding concern, OPENSSL_SMALL can be defined to remove some code that is especially large.

CMake can generate Visual Studio projects, but the generated project files don't have steps for assembling the assembly language source files, so they currently cannot be used to build BoringSSL.

Embedded ARM

ARM, unlike Intel, does not have an instruction that allows applications to discover the capabilities of the processor. Instead, the capability information has to be provided by the operating system somehow.

BoringSSL will try to use getauxval to discover the capabilities and, failing that, will probe for NEON support by executing a NEON instruction and handling any illegal-instruction signal. But some environments don‘t support that sort of thing and, for them, it’s possible to configure the CPU capabilities at compile time.

If you define OPENSSL_STATIC_ARMCAP then you can define any of the following to enabling the corresponding ARM feature.

OPENSSL_STATIC_ARMCAP_NEON or __ARM_NEON__ (note that the latter is set by compilers when NEON support is enabled).

OPENSSL_STATIC_ARMCAP_AES

OPENSSL_STATIC_ARMCAP_SHA1

OPENSSL_STATIC_ARMCAP_SHA256

OPENSSL_STATIC_ARMCAP_PMULL

Note that if a feature is enabled in this way, but not actually supported at run-time, BoringSSL will likely crash.

Running tests

There are two sets of tests: the C/C++ tests and the blackbox tests. For former are built by Ninja and can be run from the top-level directory with go run util/all_tests.go. The latter have to be run separately by running go test from within ssl/test/runner.

Both sets of tests may also be run with ninja -C build run_tests, but CMake 3.2 or later is required to avoid Ninja's output buffering.