Horton

Thread

Commits

  1. Fix build of MSVC with OpenSSL 3.0.0

  1. Fixing build of MSVC with OpenSSL 3.0.0

    Michael Paquier <michael@paquier.xyz> — 2021-10-19T05:27:05Z

    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

  2. Re: Fixing build of MSVC with OpenSSL 3.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2021-10-19T08:34:10Z

    > 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/

  3. Re: Fixing build of MSVC with OpenSSL 3.0.0

    Michael Paquier <michael@paquier.xyz> — 2021-10-19T10:52:08Z

    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

  4. Re: Fixing build of MSVC with OpenSSL 3.0.0

    Daniel Gustafsson <daniel@yesql.se> — 2021-10-19T11:09:28Z

    > 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/

  5. Re: Fixing build of MSVC with OpenSSL 3.0.0

    Michael Paquier <michael@paquier.xyz> — 2021-10-20T03:37:35Z

    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