How to statically link Indy SSL files?

问题:

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.

回答1:

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 .lib/.a files for OpenSSL for your target platform(s) (static .a files for iOS are provided at Indy's Fulgan mirror).

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.

回答2:

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.

回答3:

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.

回答4:

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