No usable OpenSSL found

[mschae]

I get the following warnings/errors when trying to install erlang 21.0:

 * crypto         : No usable OpenSSL found
 * ssh            : No usable OpenSSL found
 * ssl            : No usable OpenSSL found

I'm on MacOS 10.13.6, updated asdf-erlang and have openssl installed via homebrew:

% brew ls --versions openssl
openssl 1.0.2o_1 1.0.2p 1.0.2o_2

Any ideas?

[Stratus3D]

I'm not sure. Do you happen to have OpenSSL installed via some other method? It's possible you have some brew installed versions and one version that was installed manually by something else. Maybe kerl found the other installation first and realized it was not suitable for Erlang?

[ddresselhaus]

Ran into the same thing. Ended up just passing a valid openssl location to the --with-ssl flag into the build options.

At the end of the day, the KERL_CONFIGURE_OPTIONS line in my .zshrc file looked like this:
export KERL_CONFIGURE_OPTIONS="--disable-debug --disable-silent-rules --without-javac --enable-shared-zlib --enable-dynamic-ssl-lib --enable-hipe --enable-sctp --enable-smp-support --enable-threads --enable-kernel-poll --enable-wx --enable-darwin-64bit --with-ssl=/usr/local/Cellar/openssl/1.0.2p"

Also, I forgot to source it, which wasted even more time.

[Stratus3D]

Thanks for sharing @ddresselhaus. Closing this issue since I don't believe it's due to a bug in asdf-erlang.

[dirkholzapfel]

I could not get it to work with openssl 1.0.X, compilation with 1.1.X worked with the snippet of @ddresselhaus

--with-ssl=/usr/local/Cellar/[email protected]/1.1.1d

[javadba]

This same issue also happens on Ubuntu 18.0.4

Update: this was fixed by doing

apt-get install -Y libssl-dev

[layeddie]

I fixed this by uninstalling erlang with asdf
asdf uninstall erlang 22.2.7
then checking what version of openssl was under
ls /usr/local/Cellar/openssl
1.0.2q
export KERL_CONFIGURE_OPTIONS="--without-javac --with-ssl=/usr/local/Cellar/openssl/1.0.2q"
asdf install erlang 22.2.7

[pmarreck]

I just spent a few hours troubleshooting this problem until someone else in Slack kindly pointed me to this issue. I'd still consider this a bug since

1. I am not an SSL dev and I shouldn't have to concern myself with configuring this dependency manually, I want it to "just work"
2. Installing a package should either A) install ALL needed dependencies OR B) alert you to the important ones that are missing and explain how to fix the situation or at least point you in the right direction. Now, asdf DID say "No usable OpenSSL found", but due to the relatively recent increase in importance of this functionality (since, for example, pretty much every API call is now over HTTPS), this should error, not warn, IMHO.

FWIW, as of today (May 27, 2020), with openssl managed by Homebrew, the following line added to my .envrc (I use direnv to manage env vars on a per-project and/or global basis) worked, and should also keep pace when a new version of openssl is installed (one less thing to worry about!):

export KERL_CONFIGURE_OPTIONS="--disable-debug --disable-silent-rules --without-javac --enable-shared-zlib --enable-dynamic-ssl-lib --enable-hipe --enable-sctp --enable-smp-support --enable-threads --enable-kernel-poll --enable-wx --enable-darwin-64bit --with-ssl=$(brew --prefix openssl)"

[synalysis]

This worked for me (Erlang/OTP 23.0):
asdf plugin-update erlang

[justingamble]

I fixed this by uninstalling erlang with asdf
asdf uninstall erlang 22.2.7
then checking what version of openssl was under
ls /usr/local/Cellar/openssl
1.0.2q
export KERL_CONFIGURE_OPTIONS="--without-javac --with-ssl=/usr/local/Cellar/openssl/1.0.2q"
asdf install erlang 22.2.7

Thanks @layeddie ! Your post is what finally got me over the hurdle.

As well, I suspect that I previously did not install openssh correctly. In case it helps others, I'll give all the commands/changes that I executed on my mac (version 10.15.6):

asdf uninstall erlang 23.0.2
brew reinstall [email protected] /* NOTE: openssl 1.1 was previously already installed on my machine */

Interestingly, the brew reinstall output included some tips which seem relevant:

If you need to have [email protected] first in your PATH run:
echo 'export PATH="/usr/local/opt/[email protected]/bin:$PATH"' >> /Users/[username]/.bash_profile

For compilers to find [email protected] you may need to set:
export LDFLAGS="-L/usr/local/opt/[email protected]/lib"
export CPPFLAGS="-I/usr/local/opt/[email protected]/include"

For pkg-config to find [email protected] you may need to set:
export PKG_CONFIG_PATH="/usr/local/opt/[email protected]/lib/pkgconfig"

To apply the above, I added the following to my .bashrc:
(the KERL_CONFIGURE_OPTIONS was copied from @layeddie 's and @ddresselhaus 's posts)

export PATH="/usr/local/opt/[email protected]/bin:$PATH"
export LDFLAGS="-L/usr/local/opt/[email protected]/lib $LDFLAGS"
export CPPFLAGS="-I/usr/local/opt/[email protected]/include $CPPFLAGS"
export PKG_CONFIG_PATH="/usr/local/opt/[email protected]/lib/pkgconfig:$PKG_CONFIG_PATH"
export KERL_CONFIGURE_OPTIONS="--without-javac --with-ssl=/usr/local/Cellar/[email protected]/1.1.1g"

Then I re-installed Erlang and Elixir, and now all works fine for me:

asdf install erlang 23.0.3 /* NOTE: version bump since I originally installed 23.0.2 */
asdf install elixir 1.10.4

I became curious: was it only the change to KERL_CONFIGURE_OPTIONS that is important? Or is it also important to follow the instructions from homebrew regarding openssh? To test, I uninstalled Erlang/Elixir again, ran unset KERL_CONFIGURE_OPTIONS in that shell, and when I re-installed Erlang/Elixir in the same shell.. everything still worked correctly for me.

In short, my guess is that when I installed/upgraded openssl with homebrew, I probably ignored the output and did not setup LDFLAGS, CPPFLAGS, and PKG_CONFIG_PATH environment variables correctly. And then when I installed the latest Erlang, it could not find OpenSSL. It appears there are 2 workarounds: 1) install openssl correctly, or 2) use the KERL_CONFIGURE_OPTIONS environment variable. Or do both. :-)

[alexnum]

For me on Ubuntu 18.04 the following worked:
sudo apt install libssl-dev
When, added the following --with-ssl to the KERL_CONFIGURE_OPTIONS envvar
export KERL_CONFIGURE_OPTIONS=" --with-ssl=/usr/lib/x86_64-linux-gnu/"
Then after that just ran the kerl build normally....

[kenny-evitt]

I just ran into this again upgrading from version 23.2.4 to 24.0.6 on macOS 10.14.6 with a Homebrew OpenSSL package ([email protected]: stable 1.1.1j (bottled) [keg-only]). This seems to have worked:

$ asdf install erlang 24.0.6 --with-ssl=$(brew --prefix openssl)

[jdmarshall]

Not working with erlang 25 and LibreSSL 3.3.6 on OS X 13.3.1

[YellowApple]

Ran into the same issue on MicroOS w/ a custom-built LibreSSL (installed to $HOME/.local). Had to use a variation of the same exports in @justingamble's comment; in my .bashrc:

export PATH="$HOME/.local/bin:$PATH"
export CPATH="$HOME/.local/include:$CPATH"
export LIBRARY_PATH="$HOME/.local/lib:$LIBRARY_PATH"
export LD_LIBRARY_PATH="$HOME/.local/lib:$LIBRARY_PATH"
export LDFLAGS="-L$HOME/.local/lib $LDFLAGS"
export CPPFLAGS="-I$HOME/.local/include $CPPFLAGS"
export PKG_CONFIG_PATH="$HOME/.local/lib/pkgconfig:$PKG_CONFIG_PATH"

Even with all that, I still needed to use --with-ssl (in my case: KERL_CONFIGURE_OPTIONS="--with-ssl=$HOME/.local" asdf install erlang latest). I think the issue's in the crypto application's configure/configure.ac; specifically its hardcoded std_ssl_locations list:

std_ssl_locations="\
/usr/local \
/usr/sfw \
/usr \
/opt/local \
/usr/pkg \
/usr/local/openssl \
/usr/local/opt/openssl \
/opt/homebrew/opt/openssl \
/usr/lib/openssl \
/usr/openssl \
/usr/local/ssl \
/usr/lib/ssl \
/usr/ssl \
/"

Basically: if OpenSSL's install prefix ain't in that list, then I don't see any other automated mechanism to pick it up other than forcing it via --with-ssl.

(I know I could just install system-level OpenSSL development headers w/ sudo transactional-update pkg install openssl-devel or something, but that's less fun 😉)

[PierBusDev]

Happened to me recently on ubuntu 22.04 and erlang 26.2.2

can confirm that this solution #82 (comment) worked perfectly