Problem with openssl version on macOS for Ruby 2.6.5

[mrexox]

money-tree/lib/openssl_extensions.rb

Line 9 in 2686577

ffi_lib ['libssl.so.1.0.0', 'libssl.so.10', 'libssl1.0.0', 'ssl']

Should add 'libssl.1.0.0' in the begining of the list. Like this:

    ffi_lib ['libssl.1.0.0', 'libssl.so.1.0.0', 'libssl.so.10', 'libssl1.0.0', 'ssl']

[nakwa]

Same here (I believe)
MoneyTree is causing Rails to crash after updating OpenSSL to the latest version.

[fero46]

So after a long research, I think I solved the problem.
For some reason linking without versioning is not possible anymore:

Clients should not load the unversioned libssl dylib as it does not have a stable ABI.
So I had openssl1.1

Steps to fix:

1. brew update & brew upgrade & brew install openssl
2. cd in your openssl lib folder in my case: usr/local/opt/openssl@1.1/lib
3. copy files in /usr/lib:
   sudo cp libssl.1.1.dylib libcrypto.1.1.dylib /usr/local/lib/
4. make softlink
   sudo ln -s libssl.1.1.dylib libssl.dylib
   sudo ln -s libcrypto.1.1.dylib libcrypto.dylib

Hope I could help you.

[NikolayRys]

@fero46 Add one step:
3.5. cd /usr/local/lib/

[zeptonaut]

Just want to follow up re: @fero46's comment, which is very useful for individual developers: running those commands locally may be a great way to get the gem working locally, but having to run 3 or 4 shell commands in order to make a Gem work is very difficult on large teams (asking each developer to run those commands), or when onboarding new people to a team (what command makes this work again?). Multiply 3 or 4 commands by the average number of gems that a project relies on and it becomes clear that gems need to "just run" without any additional work in order to guarantee a reproducible setup without too much work.

[q9f]

Just want to follow up re: @fero46's comment, which is very useful for individual developers: running those commands locally may be a great way to get the gem working locally, but having to run 3 or 4 shell commands in order to make a Gem work is very difficult on large teams (asking each developer to run those commands), or when onboarding new people to a team (what command makes this work again?). Multiply 3 or 4 commands by the average number of gems that a project relies on and it becomes clear that gems need to "just run" without any additional work in order to guarantee a reproducible setup without too much work.

100%

[q9f]

fix is in #43 and let's merge this discussion with #44