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

[Rollo62 536]

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

 

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:

Quote

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 ?

const
  {$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 = '';
  {$ELSE}
    {$MESSAGE Error 'Unsupported platform'}
  {$ENDIF} 

 

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.

 

 

 

T381_GrijjySsl.zip

Edited January 19, 2021 by Rollo62

[Allen@Grijjy 44]

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.

[Rollo62 536]

@Allen@Grijjy

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 ?