On Tue, Apr 5, 2022 at 1:10 AM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > I didn't consider the case that we had NO_OPENSSL=1 because it seems a > bit bizarre to say, "No, I don't want OpenSSL—oh, wait, I do want > OpenSSL!" NO_OPENSSL is definitely strange, for example in macOS it means: do not link with openssl if it comes from homebrew or macports, but maybe use the one that comes with the system, which happens to be based on openssl anyway (based on libressl, boringssl, or even a really old version of openssl, depending on which version of the OS you got). Either way, the choice of using the openssl function this requires could work with any of those if provided with the right linker settings, but it doesn't seem worth the trouble to do, especially not for rc0. > This patch also didn't seem necessary for me on Linux when I tested, but > of course it might be necessary on some systems, so if it fixes things, > I'm in favour. Not sure if the required changes got somehow dropped in one of the rebases after your tests, but it definitely didn't work for me when tested on Linux (using debian stable or sid) and I can't see how it would work unless the crypto library is pulled in some other way, and even in that case the lack of the header should break, at least with DEVELOPER=1. Carlo
