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

[dscho]

It was reported that the vcpkg project (which we use for MSVC/Visual Studio builds of Git) upgraded OpenSSL from v1.0.x to v1.1.x, including the change of the library names. We need to adjust for that.

[dscho]

/submit

[gitgitgadget]

Submitted as pull.527.git.1579129054234.gitgitgadget@gmail.com

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"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.

Thanks.

> 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

[gitgitgadget]

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio,

On Wed, 15 Jan 2020, Junio C Hamano wrote:

> "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 ;-)

I considered this. There are actually _two_ places where this would need
to be implemented: compat/vcbuild/scripts/clink.pl and
contrib/buildsystems/engine.pl

The former is at the wrong layer, though: it is called for every single
C file that needs to be compiled to an object file. Therefore it would
need some major surgery to handle OpenSSL v1.0.x and v1.1.x gracefully.

For the latter, it is even worse: the code cannot determine whether
OpenSSL v1.0.x or v1.1.x is present because it is part of the Pipeline
that generates the `vs/master` branch that is intended to be checked out
by Visual Studio users and to work out of the box.

Meaning: to make this work, we would _also_ have to patch
contrib/buildsystems/Generators/Vcxproj.pm to add some conditional
configuration depending which OpenSSL `.dll` file is present.

Of course, this is doable, but at what cost, and at what benefit?

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

It is far from ideal a situation, I grant you that: whenever anything
breaks in the Azure Pipeline due to changes outside of our control, the
builds fail.

As far as the Visual Studio build goes, I fear at some stage we will need
to implement some sort of tighter integration with `vcpkg` so that we can
inherit the linker settings from _them_. That should make things more
robust in the future. But then, I am not aware that anybody plans on
repeating the DLL renaming stunt, not after OpenSSL demonstrated so well
how that goes. So maybe that effort would be spent in vain, dunno.

Ciao,
Dscho

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

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).

Thanks.

[gitgitgadget]

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio,

On Thu, 16 Jan 2020, Junio C Hamano wrote:

> 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).

Thank you!
Dscho

[gitgitgadget]

This branch is now known as maint.

[gitgitgadget]

This patch series was integrated into pu via git@2323784.

[gitgitgadget]

This patch series was integrated into next via git@3f081b0.

[gitgitgadget]

This patch series was integrated into master via git@2323784.

[gitgitgadget]

Closed via 2323784.