Daniel Nashed's Blog

Static linking C/C++ applications with OpenSSL

Usually applications are dynamically linked to OpenSSL.
There are pros and cons about dynamically linking OpenSSL.

Some applications dynamically link with OpenSSL and provide their own version of the OpenSSL run-time DLLs/shared libs.
This causes more issues than it solves, because you end up with multiple instances and depending on the lib path set, this can cause the wrong instance to be loaded.

Using the OS level OpenSSL share libs on the other side might leave you with an older OpenSSL version.
OpenSSL is an essential part of Linux. But not every distribution updates OpenSSL at the same time.

This means usually it is best providing OpenSSL with your application.
To avoid conflicts with other applications statically linking is a good idea.
This allows full control of the OpenSSL version and makes OpenSSL really glue into the application.

Note: Current Notes/Domino releases are statically link very current OpenSSL versions as well.


How to statically link

The two static link libs required for OpenSSL are

• libcrypto.a
• libssl.a

On Linux the is an easy way to build them for your platform and version (glibc dependency) is to start a container and build it on your own from the sources once.
The resulting static link libs can be then used for your applications.

In my build environment I have the sources of OpenSSL and switch to the right branch to build the latest release version once.
My build scripts for my applications automatically detect if static link libs are available and link OpenSSL statically (part of the makefile).


Run a new container based on Redhat UBI 9 to ensure a stable build environment (glibc 2.34).

docker run --rm -it registry.access.redhat.com/ubi9/ubi bash


Install git, compiler and make

dnf install git gcc perl make -y


Create a directory, switch to it and clone the OpenSSL GitHub project

mkdir -p /local/github
cd /local/github
git clone https://github.com/openssl/openssl.git
cd openssl


Switch to the right branch to get the latest stable version (in my case 3.3.0).

git checkout openssl-3.3.0


Finally configure and make OpenSSL

./config
make


Once the build completes, libcrypto.a and libssl.a are available in your current directory.


Clone nsh-tools and make nshcipher

cd ..
git clone https://github.com/nashcom/nsh-tools.git
cd /nsh-tools/nshmailx
make


Checkout the resulting binary

All newer NashCom tools have a --version command-line option to dump the version and OpenSSL information if the application uses OpenSSL.

/nshmailx --version

Nash!Com SMTP Mail Tool 0.9.8
Copyright 2024, Nash!Com, Daniel Nashed
OpenSSL 3.3.0 9 Apr 2024
(Build on: OpenSSL 3.3.0 9 Apr 2024)

You can see that the build and the run-time OpenSSL is the same.
Also the below dependencies don't show any OpenSSL dynamic lib.

ldd nshmailx
      linux-vdso.so.1 (0x00007fff771a0000)
      libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f26638f3000)
      libc.so.6 => /lib64/libc.so.6 (0x00007f26636ea000)
      /lib64/ld-linux-x86-64.so.2 (0x00007f266390c000)

• Comments [1]