patchmsvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> With the upgrade, the library names changed from libeay32/ssleay32 to
> libcrypto/libssl.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>     msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x
>     
>     It was reported [https://github.com/git-for-windows/git/issues/2474] 
>     that the vcpkg project (which we use for MSVC/Visual Studio builds of
>     Git) upgraded [https://github.com/microsoft/vcpkg/pull/8566] OpenSSL
>     from v1.0.x to v1.1.x, including the change of the library names. We
>     need to adjust for that.

> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-527%2Fdscho%2Fvcpkg-upgraded-to-openssl-v1.1.x-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-527/dscho/vcpkg-upgraded-to-openssl-v1.1.x-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/527
>
>  compat/vcbuild/scripts/clink.pl | 4 ++--
>  contrib/buildsystems/engine.pl  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
> index ec95a3b2d0..d9f71b7cbb 100755
> --- a/compat/vcbuild/scripts/clink.pl
> +++ b/compat/vcbuild/scripts/clink.pl
> @@ -45,9 +45,9 @@
>  	} elsif ("$arg" eq "-liconv") {
>  		push(@args, "libiconv.lib");
>  	} elsif ("$arg" eq "-lcrypto") {
> -		push(@args, "libeay32.lib");
> +		push(@args, "libcrypto.lib");
>  	} elsif ("$arg" eq "-lssl") {
> -		push(@args, "ssleay32.lib");
> +		push(@args, "libssl.lib");
>  	} elsif ("$arg" eq "-lcurl") {
>  		my $lib = "";
>  		# Newer vcpkg definitions call this libcurl_imp.lib; Do we
> diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
> index fba8a3f056..070978506a 100755
> --- a/contrib/buildsystems/engine.pl
> +++ b/contrib/buildsystems/engine.pl
> @@ -343,9 +343,9 @@ sub handleLinkLine
>          } elsif ("$part" eq "-lz") {
>              push(@libs, "zlib.lib");
>          } elsif ("$part" eq "-lcrypto") {
> -            push(@libs, "libeay32.lib");
> +            push(@libs, "libcrypto.lib");
>          } elsif ("$part" eq "-lssl") {
> -            push(@libs, "ssleay32.lib");
> +            push(@libs, "libssl.lib");
>          } elsif ("$part" eq "-lcurl") {
>              push(@libs, "libcurl.lib");
>          } elsif ("$part" eq "-lexpat") {
>
> base-commit: d0654dc308b0ba76dd8ed7bbb33c8d8f7aacd783

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > With the upgrade, the library names changed from libeay32/ssleay32 to
> > libcrypto/libssl.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >     msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x
> >
> >     It was reported [https://github.com/git-for-windows/git/issues/2474]
> >     that the vcpkg project (which we use for MSVC/Visual Studio builds of
> >     Git) upgraded [https://github.com/microsoft/vcpkg/pull/8566] OpenSSL
> >     from v1.0.x to v1.1.x, including the change of the library names. We
> >     need to adjust for that.
>
> The patch text makes me wonder if there needs to be a way to use
> either version that happens to be available, so that the version of
> Git with this change can work with older vcpkg and vice versa, but
> what would I know ;-)

>> Should this patch directly go to 'master' (or even 'maint' for v2.25
>> maintenance track)?  I do not see much point in cooking it in 'next'
>> for an extended period of time.
>
> That would be nice. As long as this patch is not merged, we will be stuck
> with failing Azure Pipelines.

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Should this patch directly go to 'master' (or even 'maint' for v2.25
> >> maintenance track)?  I do not see much point in cooking it in 'next'
> >> for an extended period of time.
> >
> > That would be nice. As long as this patch is not merged, we will be stuck
> > with failing Azure Pipelines.
>
> OK, so let's take it to 'maint' directly and merge it down to
> 'master' (and all the "more recent" integration branches).