> On 5 Dec 2019, at 02:48, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Dec 02, 2019 at 02:09:51PM +0100, Daniel Gustafsson wrote:
>> However, looking at the signatures detected by autoconf we can however get an
>> idea of which version is used. SSL_clear_options and X509_get_signature_nid()
>> first shipped in 1.0.2, while SSL_get_current_compression first shipped in
>> 0.9.8. There are also a set of functions which are new in 1.1.0 (BIO_get_data
>> et.al).
>
> I was just looking at this problem, and something does not match with
> what you wrote here. SSL_clear_options() is defined in OpenSSL from
> 0.9.8 to 1.0.2 as a macro (see ssl/ssl.h), and is defined as a
> function since 1.1.0.
Yes, I confused myself regarding the version for SSL_clear_options, except for
when it turned into a function.
> So it seems to me that we are able to correctly
> detect the presence of this function in the configure checks if
> building with 1.1.0~, but not other versions.
>
> In LibreSSL, the code has visibly always used a macro, even on their
> latest HEAD since the code has been forked from OpenSSL 1.0.1g:
> https://github.com/libressl-portable/openbsd. So we should be able
> to compile our code, still we fail to detect that we can use the
> macro.
Yes, we can't use AC_CHECK_FUNCS but would need to use AC_COMPILE_IFELSE (or a
similar check) in order to detect the macro.
> It seems to me that we have quite a couple of arguments in favor of
> dropping this configure check all together. (I saw the business
> around a364dfa as well regarding NetBSD 5.1).
>
> We can do more cleanup, and the discussion is quite different than the
> original intent of this thread, so I am going to create a new one on
> the matter.
Yes, if we're dropping older versions such that all supported versions have the
function, then keeping the autoconf check would be quite pointless.
cheers ./daniel
