On Feb 21 21:21:21, h...@stare.cz 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).
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.