7

How can I statically link Indy OpenSLL files? AFAIK only ICS allows this but for some weird reason Indy doesn't. Neither does it provide .obj files? This will allow me to avoid any dependency on the dll's.

Eric Santos
  • 131
  • 2
  • 11

4 Answers4

7

OpenSSL is primarily meant to be used dynamically. That allows for easy upgrades when new OpenSSL versions are released. However, OpenSSL can be compiled statically as well, and Indy 10.6.0+ does support linking to OpenSSL statically, but currently only supports that on iOS devices (because Apple does not allow OpenSSL to be linked dynamically). On all other platforms (including the iOS simulator), Indy links to OpenSSL dynamically by default. If you want Indy to link to OpenSSL statically on non-iOS platforms, you will have to set it up manually:

  1. compile/obtain static-link object files for OpenSSL for your target platform(s) (ie, static .a files for iOS are provided at Indy's OpenSSL-Binaries GitHub repo).

  2. update Indy's IdCompilerDefines.inc files to define USE_OPENSSL and STATICLOAD_OPENSSL for your target platform(s).

  3. add the IdSSLOpenSSLHeaders and IdSSLOpenSSLHeaders_static units to your uses clause.

  4. make sure IdSSLOpenSSLHeaders_static.pas compiles for your target platform(s) (it is currently designed for iOS, so you may need to tweak it).

The alternative is to not use OpenSSL at all, but use another SSL/TLS library that can be statically linked and is wrapped by a suitable TIdSSLIOHandlerSocketBase implementation for Indy to use. EldoS SecureBlackbox, for instance, provides such an implementation for its SSL/TLS library. And in the future, Indy is planning on adding a new IOHandler implementation for SChannel on Windows, which does not require distributing DLLs since they are already installed in the OS.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Finally an answer that i've been waiting for! :) Much appreciated! – Eric Santos Oct 30 '13 at 23:58
  • Do i have to compile .obj or .lib? – Eric Santos Nov 01 '13 at 15:56
  • Delphi does not use .lib files, so you would need .obj files instead. Indy uses .obj files for its static ZLib imports, for instance. – Remy Lebeau Nov 01 '13 at 16:35
  • I chose to use SecureBlackbox :) – Eric Santos Nov 01 '13 at 17:05
  • Since this was written over four years ago, is there any news about the planned native `IOHandler`? – Thijs van Dien Feb 15 '18 at 03:19
  • @ThijsvanDien it is still on the [todo list](https://github.com/IndySockets/Indy/issues/49). I started on some proof-of-concept code to make a secure connection using Microsoft's APIs, but it is not working yet, before it can be adapted into an IOHandler – Remy Lebeau Feb 15 '18 at 06:30
  • still in todo list? i think it was an adventure to use openssl external libraries instead of windows’s wincrypt api at the first place. it is against to sole of delphi’s single file deployment, external dll requirement is always problematic like visual basic, version mismatches, compatibility problems.. I also dont understant US export restrictions, if windows already provides all of our needs with their apis. – Mehmet Fide Sep 24 '18 at 07:59
  • 2
    @MehmetFide yes, it is still on the todo list. As for why this wasn't implemented from the very beginning, I can only speculate, since I wasn't involved in Indy's early versions. Indy is cross platform, and so is OpenSSL, so it made sense to use single code that works on all platforms. It is only in recent years that support for OpenSSL on all platforms is wavering. Also, even back when Windows was the only platform being supported, using OpenSSL instead of SChannel for SSL/TLS was still far more common. – Remy Lebeau Sep 24 '18 at 08:38
  • @RemyLebeau hi) I am now working on statically linking OpenSSL 1.0.2u in a Delphi project. How would you recommend to obtain obj files of OpenSSL? I included all relevant .c files into a single .c file and and did some nasty things to make it compile. But it doesn't work, I keep getting different weird runtime errors. How it's supposed to be done? P.S. I know about case insensitive linking issues and managed to get rid of them, but still it doesn't work( – daniel.kish Jun 14 '22 at 07:29
  • @daniel.kish I can't answer that. I've only ever used precompiled binaries made by other people, never tried to compile OpenSSL's source myself. I can tell you, though, that including .c files in other .c files is definitely wrong. Make a project, add the .c files to the project, then compile the project. – Remy Lebeau Jun 14 '22 at 08:25
  • @RemyLebeau thanks for the answer) Where did you obtain these precompiled OpenSSL binaries? And was it obj files or lib files? Because in the initial reply you wrote "compile/obtain static .lib/.a files" and Delphi doesn't seem to be able to link .lib files – daniel.kish Jun 14 '22 at 08:38
  • @daniel.kish "*Where did you obtain these precompiled OpenSSL binaries?*" - they were donated to the Indy project by other users over the years. "*was it obj files or lib files?*" - `.a` files for iOS, `.so` files for Android, `.dll`s for Windows. – Remy Lebeau Jun 14 '22 at 15:21
0

You can not statically link any DLL. The extension literally stands for "Dynamically linked library."

Not having the dependency would make the executable/library you are developing larger and subject to licensing issues while also making it more difficult to update: Why do you not want a shared object(DLL)?

Just include the DLL with your project.

RamblingMad
  • 5,332
  • 2
  • 24
  • 48
  • If you have the source you can compile the library within your app, not needing the library; but your source directory will probably be huge afterwards and you have to respect the licence e.g. if gpl then you must make your source code public domain. – RamblingMad Oct 30 '13 at 23:45
  • A DLL is "Dynamically Linked", it CAN NOT be statically linked. Also if you include the dll with your project it isn't really an external dependency, just not directly a part of the main executable. – RamblingMad Oct 30 '13 at 23:50
  • The DLL comes from code. Instead of compiling that code to DLL, compile to obj or static lib, and link that. You failed to comprehend the question. – David Heffernan Oct 31 '13 at 08:19
  • Actually, I comprehended it just fine; he just changed it. Look at the edits on the question. – RamblingMad Oct 31 '13 at 19:49
  • A bit late in the discussion but statically linking to SSL has nothing to do with DLL files, but rather compiling or getting the .lib or .obj C/C++ files and linking those directly into the Delphi .exe file. The library will then be available directly as long as there is a unit which exposes the types and functions. – Jon Lennart Aasenden Nov 26 '15 at 10:55
0

What about this: http://enigmaprotector.com/en/aboutvb.html

It's windows only (I think), but you can bind all your DLLs to your main EXE or even bind dependency DLLs to the main DLL.

Jarrod Davis
  • 1
  • 1
0

Would loading the OpenSSL DLLs from a resource into memory be a feasable alternative?

http://delphi.about.com/od/windowsshellapi/a/delphi-load-resource-dll-into-memory.htm

Lars
  • 1,428
  • 1
  • 13
  • 22
  • 1
    Only if you want to get your application blocked by virus scanners and you enjoy runnning the gauntlet of using unsupported system level hacks – David Heffernan Oct 31 '13 at 10:57