Navigating the narrow passage of OpenSSL and Net-SNMP on MacOS to install a Python module in the virtualenv

September 14, 2018

You might be familiar with the horrors of the default OpenSSL installation on MacOS. The suggested solution for this is to upgrade/install OpenSSL via Homebrew. While this works, it introduces subtle new problems that ripple outward and appear like sea monsters when least expected.

I recently upgraded my MBP to the 2018 model. While rebuilding a virtualenv for one of my projects, easysnmp refused to build:

Hmm. Digging around showed me first that when activating the virtualenv, my shell (Fish) was not keeping the alternate path locations. I want to use the OpenSSL libraries in /usr/local/opt/openssl/bin, but which openssl was continuing to show me /usr/bin/openssl. Further poking showed that this is actually happening in the embedded terminal in VS Code, not in iTerm. So, over to iTerm we go.

To review the changes, in order to force the Homebrew OpenSSL installation to come first, I have the following in ~/.config/fish/config.fish:

I nuked the virtualenv and started over. Same problem. The library linked with lcrypto.35 is in /usr/lib.

Further digging led me to net-snmp-config, which is responsible for telling the linker what libraries SNMP is linked against. Sure enough, fish is finding this in /usr/bin.

Next step: brew install net-snmp and update fish_user_paths to include /usr/local/opt/net-snmp/bin and /usr/local/opt/net-snmp/sbin. Deactivate and reactivate the venv, and voila! We’re in business…or are we?

Easysnmp builds, but when I run my app, it immediately bails with SIGABRT as it tries to call netsnmp_create_session. This means that although Easysnmp built correctly, it linked against the wrong libraries.