dynamically linking openssl

[ihla]

Is there any reason for not linking the openssl dynamically? The openssl is linked statically which is causing us troubles when building witness_node for an embedded linux (RPi) - lintian reports it as an error. Before we move to the dynamic linking we would like to know if there are any constraints we are not aware of.

[jmjatlanta]

I have never tried it, but I cannot think of a technical reason why it wouldn't work. You will need to make sure that everything is recompiled, and -fPIC is included with each compile command. I think cmake should take care of that for you.

[pmconrad]

I regularly build and run witness_node and cli_wallet on openSUSE linux, which doesn't provide static libs in system packages. I even build with -D Boost_USE_STATIC_LIBS=OFF. Never had problems in that regard.

[abitmore]

Just a note, to distribute binaries (Windows and perhaps macOS), the libs need to be statically linked.

[ihla]

thx for hints, our finding: in order to force dynamic linking on linux systems which allow both static and dynamic linking, CMAKE_FIND_LIBRARY_SUFFIXES must set correct order like this: SET(CMAKE_FIND_LIBRARY_SUFFIXES .so .a) - in original CMakeLists.txt it is SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a;.so") that's why the libs are tried to link statically first.

[ryanRfox]

@bitshares/core-dev are the changes @ihla mention above a desired change to our CMAKE build script? If yes, seems like a quick PR. If not, we should capture this within our build documentation so other devs are aware.

[jmjatlanta]

@ryanRfox I believe this will fix some things and cause problems for others (i.e. abit's comment above). Documenting this is a great idea.

[jmjatlanta]

This is not a "How To", just some background information...

Short (TL;DR) version:

If you use a cUrl library that is statically linked with OpenSSL, you will need to statically link to cUrl and the same version of OpenSSL that was used to create the cUrl library.

If you use a cUrl library that is dynamically linked with OpenSSL, you will need to dynamically link to cUrl and OpenSSL, and will probably need to use the same version of OpenSSL that was used to build the cUrl library.

Long-winded version:

Many software projects package up their components into "libraries". These are not usually products by themselves, but pieces of products, or "components". There are many advantages of packaging these things up this way. One of the biggest is being able to use such components in several products.

OpenSSL is a good example of this. They provide some complicated and intricate encryption and security algorithms, package it up, and allow it to be used by thousands of other software projects. cUrl uses it to make SSL connections to remote servers. BitShares uses it for the same thing, as well as in a few other areas.

How you package your component is important. Often, one component is packaged in a variety of different ways to allow others to choose how they want to use it. Such decisions as operating system, hardware, and whether the code should be optimized for speed or being able to trace down problems. Also, the component can be kept separate and "shared" between many applications, or placed inside the application, without the ability to separate one from the other (a.k.a. "static").

cUrl needs the OpenSSL library. BitShares needs OpenSSL and cUrl. When BitShares needs to be compiled into an application, all components must be using the same library (there are exceptions, but those are special cases). So if cUrl was packaged up with (for example) OpenSSL "static", with debug information, and for Linux, BitShares must do the same. Otherwise, the linker (the application that makes other applications) gets confused. "You told me to call a particular OpenSSL function, but I do not know which one you want!"

When Bitshares is compiled, and is using the same OpenSSL components that cUrl did when it was compiled, everyone is happy. There is only 1 version of each OpenSSL function to choose from. The linker is happy, and the application gets built.

Note 1: This applies to Windows users as well, although the terminology is a bit different. They call "shared libraries" "DLLs".

Note 2: All of the above should not be taken as rules. There can be some "bending" to make things work, but things will probably be more smooth if you can match all your pieces (versions, products, static/dynamic, etc.).

[ryanRfox]

Assigning to @cedar-book to update documentation. We will together with the devs to ensure we capture this properly.

[cedar-book]

@ryanRfox, I have added this page: OpenSSl and another Library in Getting started section (Feb.25). Let me know any thoughts. --> I am done.

[pmconrad]

Good, thanks!