LibreSSL and OpenSSL and *SSL

Jan Stary hans at
Thu Feb 22 12:16:04 UTC 2018

On Feb 21 21:21:21, hans at wrote:
> While it's true that the two version are not completely compatible,
> in e.g. the opusfile port that started this, the incompatibilty
> is completely artificial.
> Opus is an audio codec - why does it need to link with -lssl?
> It wants to play remote audio files, and for that it might need
> to make a secure connection. That's a very basic thing which should
> not depend on this or that version of this or that implementation.
> The noncompatibility is tests for OPENSSL_VERSION_NUMBER<0x10002000L etc
> that already assume that OPENSSL is the only implementation. The patch
> is trivial: add defined(LIBRESSL_VERSION_NUMBER) in 11 places.
> Obviously, I have not studied all the ports that depend on OpenSSL now,
> and I don't doubt that many of them depend on *SSL in a nontrvial way.
> But I would be willing to bet that in a lot of cases, the noncompatibilty
> between versions is similarly artificial: upstream simply did not take
> LibreSSL into consideration (yet).

Example: www/lynx

The latest release (which is the release in MP) is 2.8.8.
It was released in February 2014, before LibreSSL existed.

Does it "support" LibreSSL? Yes it does: with LibreSSL installed
and with "depends_lib-append path:lib/libssl.dylib:openssl" it will
compile against the installed LibreSSL, and works just fine.


Now, this is a web browser. How much more involved can SSL usage get?
Yet it just works. I mean this as an example of showing that the
OpenSSL/LibreSSL "conflict" is largely avoidable.


More information about the macports-dev mailing list