Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> From my limited knowledge of OpenSSL libraries, I think the error has >> more to do with 'SSL_library_init()' , which appears like a >> constructor to the OpenSSL library. I found these emails regarding >> "if" cases around this function. Please check out these patches: >> 1. Rosen Penev: >> https://lore.kernel.org/git/20181227023548.396-1-rosenp@xxxxxxxxx/ > > I remember that one. And I agreed with Junio that the documentation > suggests that the call is _optional_, while the patch suggests that it > would be _incorrect_ instead. > > And looking at > https://www.openssl.org/docs/man1.1.1/man3/SSL_library_init.html suggests > to me that it is still supported. > > Having said that, if I look at the headers installed for `libssl-dev` > version `1.1.1-1ubuntu2.1~18.04.5` in my Ubuntu installation, I see that > `/usr/include/openssl/ssl.h` defines that symbol as: > > # define SSL_library_init() OPENSSL_init_ssl(0, NULL) > > but _only_: > > # if OPENSSL_API_COMPAT < 0x10100000L > > So maybe that disagrees with the documentation that says that > SSL_library_init() is optional? > > The curious thing is that `OPENSSL_API_COMPAT` is not even defined > anywhere. So maybe it _is_ the right thing to also `#define > SSL_library_init() (void)` in the diff you listed above? > > _Maybe_ guarded within `#ifndef SSL_library_init ... #endif` guards? > >> 2. eroen: https://lore.kernel.org/git/20170112104219.563497-1-git-scm@xxxxxxxxxxxxxx/ > > That sounds like a good suggestion, too. > >> Are the fixes made in these patches relevant here. Please let me know >> if I'm going wrong. > > Yes, both threads are relevant, and if you can reconcile them into a patch > that makes Git compile with OpenSSL v1.1.1, I will try my best to review > them (Cc: me, just in case). I agree with the above reasoning and the suggestion given by Bates in https://lore.kernel.org/git/66967e0e-8bd9-f4b6-d2d4-ccce9004f42e@xxxxxxxxxxxxxxxx/ sounds like a reasonable one. Thanks for digging and double-checking these two previous efforts, and giving another round of thoughts on them.
