msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x
PATCH 1/1 msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x
From: Johannes Schindelin <[email protected]>
With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl.
---
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(-)
compat/vcbuild/scripts/clink.pl +2 -2
@@ -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
contrib/buildsystems/engine.pl +2 -2
@@ -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
Signature · 1 line
gitgitgadget
"Johannes Schindelin via GitGitGadget" <[email protected]>
Quoted 6 lines · writes:
From: Johannes Schindelin <[email protected]>
With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl.
Signed-off-by Johannes Schindelin <[email protected]>
Quoted 8 lines
---
msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.xIt 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.
Quoted 42 lines
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/527compat/vcbuild/scripts/clink.pl | 4 ++-- contrib/buildsystems/engine.pl | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)compat/vcbuild/scripts/clink.pl +2
-2@@ -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 wecontrib/buildsystems/engine.pl +2
-2@@ -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
Hi Junio,
Quoted 18 lines · Junio C Hamano
"Johannes Schindelin via GitGitGadget" <[email protected]>
Quoted 6 lines · writes:
From: Johannes Schindelin <[email protected]>
With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl.
Signed-off-by Johannes Schindelin <[email protected]>Quoted 8 lines
---
msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.xIt 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.
Quoted 4 lines
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?
Quoted 3 lines
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
Quoted 6 lines · Johannes Schindelin
Quoted 3 lines
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.
Hi Junio,
Quoted 11 lines · Junio C Hamano
Quoted 6 lines · Johannes Schindelin
Quoted 3 lines
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