and, btw, once I have the compiler issues sorted out, statically linking openSSL is pretty straight forward. I'm using the openSSL 1.1 version of Indy (currently, just a PR) and I compiled the static headers in, and added:
{$IFDEF FPC}
{$IFDEF DARWIN}
{ On MacOS, and only on MacOS, we statically bind to openSSL
because the openSSL libssl.dylib doesn't bind to libcrypto.dylib
in a way that will be approved by the OSX loader for hardened
apps. But it's not worth the effort to statically bind on other
platforms - On linux, openSSL is baked in. On windows, we distribute
it with the application
}
{$LINKLIB libcrypto.a}
{$LINKLIB libssl.a}
{$ENDIF}
{$ENDIF}
Abd bingo, it's compiled into my executable, as long as I have the openssl libraries on my path. Building them is easy (on anything but windows) - just follow the openssl instructions and then make sure those two files are on the path.
What I haven't figured out is that my practice is to use dynamic loading otherwise. So I want an Indy package that doesn't bind to either dynamic or static, and the application that uses it decides which way it's going to be bound. Lazarus packages just don't work that way. I can't even figure out how to $IFDEF the package for dynamic vs static based on OS, since all the units have the same names and just differ by path - and I don't know how to do that with the Lazarus package system. So for now, all FPC applications are statically bound to the .so / .dll. I will probably get around to statically linking to the .a
btw, can't tell you how much confusion I had because of the double use of 'static' there - statically linked to the .dll is totally different in meaning to being statically linked to the code directly. I went down several dead ends because of that