Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dynamically linking openssl #1304

Closed
ihla opened this issue Sep 3, 2018 · 10 comments

Comments

Projects
6 participants
@ihla
Copy link

commented Sep 3, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 3, 2018

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

@ihla

This comment has been minimized.

Copy link
Author

commented Sep 4, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 4, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 25, 2018

@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 comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 24, 2019

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

@ryanRfox ryanRfox added this to To do in Feature Release (3.1.0) via automation Feb 24, 2019

@cedar-book

This comment has been minimized.

Copy link

commented Feb 25, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

Good, thanks!

@pmconrad pmconrad closed this Apr 16, 2019

Feature Release (3.1.0) automation moved this from To do to Done Apr 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.