Mirror of forum.nim-lang.org

495 :: Statically linking SSL on Windows

• throwaway123 (orginal) [2014-07-12T22:53:36+02:00] view original

  Hi there,

  I'm trying to build a standalone executable (and NOT having an installer program is an hard requirement) which has to download files over HTTPS.

  I noticed that the sockets library relies on OpenSSL to open the SSL tunnel. The corresponding Nimrod wrapper seems to reference the DLL by name and, indeed, the generated C source code contains a call to nimLoadLibrary (which I assume is a wrapper to dlopen()/LoadLibrary() -- didn't look into that in details but Nimrod's C FFI seems to work in a manner similar to Python's ctypes).

  Is there a (simple) way to force the compiler to not load the library and just assume the symbols will be there when, at link time, I bring them in from the OpenSSL static library?

  I guess that since Nimrod, in the end, generates C source code and calls a C compiler this should be theoretically possible but I'm not sure how/if it is feasible as of yet.

---

• Demos (orginal) [2014-07-13T00:46:08+02:00] view original

  Use the --dynlibOverride:ssl compiler option to prevent the compiler from generating the library loading code. You can then pass the relevant options to get you C compiler to link ssl statically. I think there may also be a way to tell sockets not to use ssl in the first place, removing the need for the library in the first place.

---

• throwaway123 (orginal) [2014-07-13T15:35:17+02:00] view original

  Hi,

  I managed to prevent the compiler from generating calls to nimLoadLibrary, however no matter how I try, while I seem to be able to tell the compiler/linker to look up symbols in libeay32.a and ssleay32.a but I can't get it to actually bundle the static library inside the exe. That is, the resulting executable is always the same size even though I expect it to bump up in size considering that libeay32.a is > 2 Mb big. Also if I peek into the final executable with Dependency Walker I always see references to LIBEAY32.DLL and SSLEAY32.DLL which is weird since nowhere on gcc or ld command line I tell it to dynamically link to those library. Heck, I even tried stripping the dynlib pragma everywhere from openssl.nim.

  To summarise:

  • If I build my executable like this: nimrod c -d:ssl main.nim I get the standard behaviour which, I guess, is to LoadLibrary() libeay32 whenever there's a need to open an SSL socket.
  • If I build it with nimrod c -d:ssl --dynlibOverride="(ssleay32|libssl32).dll" --dynlibOverride=libeay32.dll main.nim I get the Nimrod compiler to not generate library loading code and I have the linker rightfully complaining about missing symbols. Note that as soon as I add these two --dynlibOverride flags the final executable gets dynamically linked to LIBEAY32.DLL and SSLEAY32.DLL as shown by "Dependency Walker".

  At this point I tried a couple of alternatives to statically link OpenSSL:

  • I tried to pass --passL=lib/libeay32.a --passL=lib/ssleay32.a and that solves the "missing symbols" error but somehow the final executable is always the same size as the executable built without --dynlibOverride
  • I tried variations like --passL=-Llib --passL=-leay32 --passL=-lssleay32 (after renaming ssleay32.a to libssleay32.a). No success.
  • I tried further variations like --passL=-Wl,-Llib --passL=-Wl,-leay32 --passL=-Wl,-lssleay32 to pass arguments directly to the linker. No success.

  At this point I also tried passing --passC=--verbose --passL=--verbose --passL=-Wl,--verbose to inspect command line arguments passed to MinGW's gcc.exe and ld.exe but as far as I know, it's picking stuff from where I'm expecting it to.

  It's been about 10 years since I last used Windows for more than playing casual games so I might be missing something obvious here :)

  For those curious: the project is hosted on GitHub and available here: https://github.com/lvillani/just-install/tree/nimrod

---

• Araq (orginal) [2014-07-13T21:36:52+02:00] view original

  Perhaps you need to build your own libeay32.a that doesn't link against the DLL.

---