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).

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.

/opt/local/bin/lynx:
        /opt/local/lib/libidn.11.dylib 
        /opt/local/lib/libncurses.6.dylib
        /opt/local/lib/libssl.43.dylib
        /opt/local/lib/libcrypto.41.dylib
        /usr/lib/libSystem.B.dylib
        /opt/local/lib/libintl.8.dylib
        /opt/local/lib/libiconv.2.dylib

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.

        Jan

Reply via email to