Recent

Author Topic: Static Linking OpenSSL and OSX version  (Read 24173 times)

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 363
Re: Static Linking OpenSSL and OSX version
« Reply #30 on: December 07, 2021, 11:18:18 am »
Anyway, thanks for all the help - it really made a difference. And as was pretty obvious, I was way out of my depth with OSX and with linking questions

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2020
  • Former Delphi 1-7, 10.2 user
Re: Static Linking OpenSSL and OSX version
« Reply #31 on: December 07, 2021, 11:20:41 am »
You're welcome!

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 363
Re: Static Linking OpenSSL and OSX version
« Reply #32 on: December 09, 2021, 10:44:32 am »
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

Remy Lebeau

  • Hero Member
  • *****
  • Posts: 1311
    • Lebeau Software
Re: Static Linking OpenSSL and OSX version
« Reply #33 on: December 09, 2021, 07:24:17 pm »
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

Indy has an IdSSLOpenSSLHeaders_static.pas unit for static-linking to OpenSSL's .a files.  But that unit is currently only used for iOS.  So, you could try updating that unit to support OSX too (and then add the unit to your uses clause with an {$IFDEF}), as well as update IdCompilerDefines.inc to define STATICLOAD_OPENSSL for OSX, and then recompile Indy.
« Last Edit: December 09, 2021, 07:25:55 pm by Remy Lebeau »
Remy Lebeau
Lebeau Software - Owner, Developer
Internet Direct (Indy) - Admin, Developer (Support forum)

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 363
Re: Static Linking OpenSSL and OSX version
« Reply #34 on: December 09, 2021, 08:41:30 pm »
Hey Remy, I do have STATICLOAD_OPENSSL in my idCompilers.inc, but the IdSSLOpenSSLHeaders_static unit isn't in the openSSL 1.1 PR (not that I can see anyway). But I didn't ask about compiling, which I could figure out for sure. The problem for me is the way Lazarus Package management works

Remy Lebeau

  • Hero Member
  • *****
  • Posts: 1311
    • Lebeau Software
Re: Static Linking OpenSSL and OSX version
« Reply #35 on: December 10, 2021, 06:46:37 pm »
the IdSSLOpenSSLHeaders_static unit isn't in the openSSL 1.1 PR

Because the PR doesn't use the IdSSLOpenSSLHeaders unit.  It has its own set of units for importing OpenSSL 1.1.x.  I haven't reviewed the PR yet, so I don't know whether it includes any static-linking support or not.
Remy Lebeau
Lebeau Software - Owner, Developer
Internet Direct (Indy) - Admin, Developer (Support forum)

 

TinyPortal © 2005-2018