[FFmpeg-devel] [PATCH] Fix build with LibreSSL
h.leppkes at gmail.com
Wed Dec 7 12:36:45 EET 2016
On Wed, Dec 7, 2016 at 7:13 AM, Matt Oliver <protogonoi at gmail.com> wrote:
> On 30 October 2016 at 17:57, Michael Forney <mforney at mforney.org> wrote:
>> On 10/29/16, Matt Oliver <protogonoi at gmail.com> wrote:
>> > This also seems a bit odd, why is libreSSL setting an openssl version
>> > number of 1.1.0 or higher when it doesnt actually conform to the
>> > corresponding openssl version. LibreSSl setting the openssl version
>> > to 2.0.0 seems to be problematic and causes problems not just for ffmpeg.
>> > Of course theres not much we can do about that but perhaps an alternative
>> > to Michaels suggestion would be to just add a single check near the top
>> > the file that checks for libressl and then redefines the openssl version
>> > the api libressl actually supports. i.e.
>> > #ifdef LIBRESSL_VERSION_NUMBER
>> > #undef OPENSSL_VERSION_NUMBER
>> > #define OPENSSL_VERSION_NUMBER 0x1000107fL
>> > #endif
>> > This I believe is what some other projects have done to avoid this issue
>> > and is rather simple to add and prevents further clutter in our
>> > I dont have any preference between this and the other suggestion, im just
>> > providing some alternatives. The above is pretty simple so if it works
>> > you i can write up a patch for that pretty easily.
>> I'm not sure why libressl sets OPENSSL_VERSION_NUMBER to 0x20000000L.
>> Maybe so that they can pick and choose which openssl APIs to implement
>> (rather than everything up through some version)?
>> I'm fine with any of the suggested approaches. I just went with
>> !defined(LIBRESSL_VERSION_NUMBER) in my original patch because that's
>> what I've seen projects like curl, wpa_supplicant, and openvpn do. It
>> also seems to be what openbsd is doing itself with patches in its
>> ports tree (xca, stunnel, postfix).
> Something should actually be done about this. Im fine with the original
> patch but the blocker seems to have been Michael. Im not such a huge fan of
> cluttering configure and slowing it down more for a small issue (as there
> could get progressively more and more difference between the 2 projects) so
> as an inbetween what about creating HAVE_BIO_METHODS but do so only locally
> in tls_openssl using something like:
The way I see it, if LibreSSL pretends to be OpenSSL and expects to
run with the same code in downstream projects, it should also match
its API and/or version checks. If it doesn't, we cannot realistically
Otherwise, we should drop any illusions of treating them the same,
especially if as you say they diverge more and more in the future.
In any case, configure is the place to check these things, heuristics
in the code is what configure is designed to avoid.
More information about the ffmpeg-devel