Sergei Ianovich

> This has a flaw. An application that's linked against libcrypto.a will not include _everything_, it will only include the object files from it that contains unresolved symbols. If the...

> but cant both libcrypto version be installed side-by-side? Sure ``` $ ls -l /usr/lib/x86_64-linux-gnu/libcrypto* -rw-r--r-- 1 root root 5464768 Nov 24 12:53 /usr/lib/x86_64-linux-gnu/libcrypto.a lrwxrwxrwx 1 root root 16 Nov...

> Is your plan to make the bind_engine abort nicely if either the application or the engine is linked against a static libcrypto.a or a different major version of the...

> What a weird idea! Is your node executable linked against a static libcrypto.a ? And aren't there ways to export symbols from an executable to the shared objects like...

It doesn't work, of course, But it has two ways to fail. With my patch to the engine, it just fails to load. Without my patch, it says it loaded...

> There is no need to export symbols from executables on systems with GNU `ld`. `gcc` determines symbols from header files, `ld`leaves them unresolved at link time. `ld` keeps a...

> As I pointed out, this is not generally supported. Windows, NonStop, and zOS AFAIK do not support loading like this. Please use caution about this whole concept. This patch...

> I still don't understand how that is supposed to work. How would you detect a mismatch betwenn 1.1.1a-engine and 1.1.1m-application? This is a great question. A proposed solution is...

> > Unless something like `--gc-sections` is passed to the linker, all symbols from `libcrypto.a` should land in the executable. > > A simple test proves your hypothesis to be...

And for reference, when the executable is dynamically linked to `libcrypto.so`, tests built with my patch work fine.