How to compile/build openssl

This post lists the steps you have to take in order to compile OpenSSL from source for a unix-like platform in both a default and a non-default directory.

The compile was made on a Kali Linux OS, gcc and g++ version: 9.3.0, ld version: 2.35

Steps into

Get a local copy of the Git Repository by cloning the original OpenSSL repository with the following command:

git clone git://git.openssl.org/openssl.git

or from the GitHub mirror with the command:

git clone https://github.com/openssl/openssl.git

In the above links you can find the development branch of OpenSSL. If you’re looking for the production release have a look at OpenSSL’s page.

Compile in the default directory

If you intend to compile the source in the default directory, after you clone the OpenSSL repository change to this directory with:

cd openssl

Next step is to run the configuration script that will setup the environment for the compile. This script has a variety of options you can select, like for example the platform (linux-x86_x64 in this case) or/and the option no-shared which will compile the source code without generating shared library objects. You can run the script by invoking:

./Configure linux-x86_64

The configuration script creates the files: configdata.pm and Makefile

After this step we can run the command that reads the Makefile and compiles the source code:

make

Compile in a non-default directory

After you clone the source code from the git repository instead of changing to the openssl directory you need to create the non default directory where the source will be compiled and change to it:

mkdir openssl-build

cd openssl-build

In order to setup the environment, you need to run the configuration script from the default OpenSSL (the one you cloned from git). If this directory is /home/Downloads/openssl, in order to run the configuration script you need to invoke inside openssl-build:

/home/Downloads/openssl/Configuration

The script generates the following files and directories:

apps  configdata.pm  crypto  engines  fuzz  include  Makefile  ms  ssl  test  tools  util

Same as before, in order to compile the source code you need to invoke:

make

After make, the directory contains a number of files: shared object (.so), static library (.a), pkg-config (.pc) and map (.map). The new directory contents are now:

apps  configdata.pm  crypto  engines  fuzz  include  libcrypto.a  libcrypto.map  libcrypto.pc  libcrypto.so  libcrypto.so.1.1  libssl.a  libssl.map  libssl.pc  libssl.so  libssl.so.1.1  Makefile  ms  openssl.pc  ssl  test  tools  util

Shared Object vs Static Library Files

What’s the difference between a shared object (.so) and a static (.a) library anyway?

The tool ldd answers this question:

ldd libcrypto.so

        linux-vdso.so.1 (0x00007fff57119000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffa1d25b000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffa1d239000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa1d074000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffa1d55c000)

As you can see, the shared object library file relies on additional library files that will request in run-time, when the library gets loaded in memory.

lib libcrypto.a

        not a dynamic executable

The static version of this library doesn’t dynamically load other libraries as any library it requires comes statically linked in the generated file.

You now have both dynamic and static libraries you can use in other projects!

References

[1] https://www.openssl.org/source/