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
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:
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:
The configuration script creates the files:
After this step we can run the command that reads the Makefile and compiles the source code:
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:
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
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:
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?
ldd answers this question:
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.
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!