On April 5, 2022 6:48 PM, Carlo Arenas wrote: >To: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx>; Carlo Marcelo Arenas Belón ><carenas@xxxxxxxxx>; rsbecker@xxxxxxxxxxxxx; Junio C Hamano ><gitster@xxxxxxxxx>; Git Mailing List <git@xxxxxxxxxxxxxxx>; git- >packagers@xxxxxxxxxxxxxxxx >Subject: Re: [ANNOUNCE] Git v2.36.0-rc0 - Build failure on NonStops > >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. I had to be explicit and override the LDFLAGS to include -lcrypto and -lssl at least for git-daemon with the wrapper.c patch. Testing is still going - currently at t5531 on the ia64 NonStop variant without problems. I deliberately picked the more finicky of the two systems since x86 uses a slightly simpler OpenSSL with the x86 hardware randomizer.
