Jump to content
Sign in to follow this  

OpenSsl 1.1.1 library, why is it working without binding static libraries ?

Recommended Posts

Hi there,

I had some time to check out the great OpenSsl library from Grijjy / @Allen@Grijjy,

and I found that its working even without binding any libraries to it.

The original FMX sample showed some issues, so I just created a brand new Rx10.4.1 project and moved the main unit to it.


Beside the Grijjy Foundation, I've put no static linked files yet in the deployment, to check this library out step-by step.

Of coarse for Win32 I need the enclosed DLL's in the EXE folder, that's no surprise.


It puzzled me that for Android and iOS, as well as for Macos, I don't need to add any library at all to the library tree/deployment :classic_blink:


Even in Allens post, there is the note, I've misinterpreted that it should be added directly to the projects library tree, or by deployment manager or some other hacky means:


For the current examples in this article, we provide the pre-built binaries for the platforms that use a dynamic library (Win32, Win64, macOS-32, Linux) and also those that utilize a static library (Android32, Android64, iOS, macOS-64) for OpenSsl.

Also Embarcadero has notes about OpenSsl,


Which leads to the conclusion at least iOS would need some external download of static libraries.

In the libraries const section, I can spot the different static/dynamic names, but where and do they bind to ?

  {$IF Defined(WIN32)}
  LIB_CRYPTO = 'libcrypto-1_1.dll';
  LIB_SSL = 'libssl-1_1.dll';
  _PU = '';
  {$ELSEIF Defined(WIN64)}
  LIB_CRYPTO = 'libcrypto-1_1-x64.dll';
  LIB_SSL = 'libssl-1_1-x64.dll';
  _PU = '';
  {$ELSEIF Defined(ANDROID64)}
  LIB_CRYPTO = 'libcrypto-android64.a';
  LIB_SSL = 'libssl-android64.a';
  _PU = '';
  {$ELSEIF Defined(ANDROID32)}
  LIB_CRYPTO = 'libcrypto-android32.a';
  LIB_SSL = 'libssl-android32.a';
  _PU = '';
  {$ELSEIF Defined(IOS)}
  LIB_CRYPTO = 'libcrypto-ios.a';
  LIB_SSL = 'libssl-ios.a';
  _PU = '';
  {$ELSEIF Defined(MACOS32)}
  LIB_CRYPTO = 'libssl-merged-osx32.dylib'; { We unify LibSsl and LibCrypto into a common shared library on macOS }
  LIB_SSL = 'libssl-merged-osx32.dylib';
  _PU = '_';
  {$ELSEIF Defined(MACOS64)}
  LIB_CRYPTO = 'libcrypto-osx64.a';
  LIB_SSL = 'libssl-osx64.a';
  _PU = '';
  {$ELSEIF Defined(LINUX)}
  LIB_CRYPTO = 'libcrypto.so';
  LIB_SSL = 'libssl.so';
  _PU = '';
    {$MESSAGE Error 'Unsupported platform'}


I've put my test code as a wrapper around the original code, basically just adding the new project files.

It seems the magic happens, because the libraries were sitting all side-by-side to the calling unit.



The OpenSSL_Api unit find these local files in the same folder, and is able to bind them correctly.

I didn't know that this is possible, I thought they have to be in the same project folder,
and at least cross-platform make another hazzle to bind depending on the OS.


Good to know that its enough to provide library+unit together, that gives much more room to cleanup libraries.


I've put my wrapper code enclosed for testing, while the originally library files from Grijjy should be placed in the Src folder.
The missing files you can get from here.

I hope Allen don't mind.





Edited by Rollo62

Share this post

Link to post

Sorry, missed your original post on this.  I don't mind your efforts here.  OpenSsl is particularly tricky because quite often it is installed with the operating system and if you use dynamic library version the imports will get confused about which library you are using, since there are 2 of them that cross-reference each other.  To avoid this, I try to build the static versions which are linked directly into the project using the "dependency" keyword.  Also, the Mac was particularly a pain because symbolic linking will force the dynamic library to find OpenSsl elsewhere so I merged both libraries into one to avoid that.  But yes, placing all the libraries into a single path with the header unit avoids a lot of frustration for static libraries.

Share this post

Link to post


Thanks for the info.

It seems that a "dependency" keyword has not hit me yet, or I overlooked it many times,
but I cannot really guess what its good for and how its working.

Since I  can't find really useful information on this, only from your other blog post:

//A way to add the dependency automatically is 
// by adding the dependency keyword to one of the API imports in the source code. For example:
procedure foo; cdecl external LIB_FOO name PREFIX + 'foo'
  {$IFDEF MACOS64}dependency 'c++'{$ENDIF};

Maybe you have some hints and could point me to a link, where I'm able to find more information regarding this mysterious keyword ?

Is this only available for Macos64 then ?


Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this