Обсуждение: Fixing build of MSVC with OpenSSL 3.0.0
Hi all, $subject has been noticed on github here: https://github.com/postgres/postgres/pull/70/commits Looking at the MSIs of OpenSSL for Win64 and Win32, there are no changes in the deliverable names or paths, meaning that something as simple as the attached patch is enough to make the build pass. Any opinions? -- Michael
Вложения
> On 19 Oct 2021, at 07:27, Michael Paquier <michael@paquier.xyz> wrote: > Looking at the MSIs of OpenSSL for Win64 and Win32, there are no > changes in the deliverable names or paths, meaning that something as > simple as the attached patch is enough to make the build pass. Makes sense. > Any opinions? I think we can tighten the check for GetOpenSSLVersion() a bit since we now now the range of version in the 1.x.x series. For these checks we know we want 1.1.x or 3.x.x, but never 2.x.x etc. How about the (untested) attached which encodes that knowledge, as well as dies on too old OpenSSL versions? -- Daniel Gustafsson https://vmware.com/
Вложения
On Tue, Oct 19, 2021 at 10:34:10AM +0200, Daniel Gustafsson wrote: > I think we can tighten the check for GetOpenSSLVersion() a bit since we now now > the range of version in the 1.x.x series. For these checks we know we want > 1.1.x or 3.x.x, but never 2.x.x etc. > > How about the (untested) attached which encodes that knowledge, as well as dies > on too old OpenSSL versions? One assumption hidden behind the scripts of src/tools/msvc/ is that we have never needed to support OpenSSL <= 1.0.1 these days (see for example HAVE_X509_GET_SIGNATURE_NID always set to 1, introduced in 1.0.2) because the buildfarm has no need for it and there is no MSI for this version for years (except if compiling from source, but nobody would do that for an older version anyway with their right mind). If you try, you would already get a compilation failure pretty quickly. So I'd rather keep the code as-is and not add the extra sudden-death check. Now that's only three extra lines, so.. -- Michael
Вложения
> On 19 Oct 2021, at 12:52, Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Oct 19, 2021 at 10:34:10AM +0200, Daniel Gustafsson wrote: >> I think we can tighten the check for GetOpenSSLVersion() a bit since we now now >> the range of version in the 1.x.x series. For these checks we know we want >> 1.1.x or 3.x.x, but never 2.x.x etc. >> >> How about the (untested) attached which encodes that knowledge, as well as dies >> on too old OpenSSL versions? > > One assumption hidden behind the scripts of src/tools/msvc/ is that we > have never needed to support OpenSSL <= 1.0.1 these days Right, I was going off the version stated in the documentation which doesn't list per OS requirements. > ..(see for > example HAVE_X509_GET_SIGNATURE_NID always set to 1, introduced in > 1.0.2) because the buildfarm has no need for it and there is no MSI > for this version for years (except if compiling from source, but > nobody would do that for an older version anyway with their right > mind). If you try, you would already get a compilation failure pretty > quickly. So I'd rather keep the code as-is and not add the extra > sudden-death check. Fair enough, there isn't much use in protecting against issues that will never happen. The other proposal, making sure that we don't see a version 2.x.x creep in (in case a packager decides to play cute like how has happened in other OS's) seem sane to me, but I'm also not very well versed in Windows so you be the judge there. -- Daniel Gustafsson https://vmware.com/
On Tue, Oct 19, 2021 at 01:09:28PM +0200, Daniel Gustafsson wrote: > The other proposal, making sure that we don't see a version 2.x.x creep in (in > case a packager decides to play cute like how has happened in other OS's) seem > sane to me, but I'm also not very well versed in Windows so you be the judge > there. If that happens to become a problem, I'd rather wait and see when/if we reach this point. For the MSIs the PG docs point to, the first patch is more than enough. -- Michael