Re: BUG #15789: libpq compilation with OpenSSL 1.1.1b fails onWindows with Visual Studio 2017

On Fri, Jun 21, 2019 at 12:23:21PM +0200, Juan José Santamaría Flecha wrote:
> Since the third parameter is only currently used with OpenSSL
> libraries, I thought it would be ok to touch it in this patch. The
> reasson behind doing so was to keep the logic for the new fancy
> library naming tidy. Documenting better is not a thing I can argue
> against, xlib stands for expanded library name as used in
> GetAdditionalLinkerDependencies and maybe a comment like this can make
> things clearer:
>
> # The parameter $slib is for sufixed run-time library.
> # When available it will be added, if not it silently defaults to $lib.
>  sub AddLibrary

That's a sensible argument.  Perhaps your way of doing is much better
at the end.  I still found the patch hard to follow in the changes it
did though, so documenting things for the changes you are doing would
help anybody looking at this code in the future.

> No problem with that. Even more so, it can return 4 values: the 3
> digits and the letter. For example, 1.1.1b would be (1, 1, 1, b).

There are two reasons why we need to know the version of OpenSSL
dynamically:
1) Enforce the correct compilation flags in pg_config.h
2) Select the correct library paths.
OpenSSL keeps API compatibility in their stable branches, so 1. would
not be an issue.  I suspect as well that the installers we use for
Postgres compilation are not going to change their layer in a minor
version update.  So having only 3 digits is enough.  2 likely not.  I
would just keep it at three for now.

Could you send an updated patch?  I would like to look at this stuff
rather sooner than later as OpenSSL 1.0.2 goes EOL in a couple of
months, so there is going to be demand for it.
--
Michael