ReadKey.c: loadable library and perl binaries are mismatched

[mehrdadn]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

git version 2.16.1.windows.4
cpu: x86_64
built from commit: ef6d451bbfef86a529ebf12620289e0f15a93d8e
sizeof-long: 4

The problem also occurs on the 32-bit version.

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Microsoft Windows [Version 10.0.16299.214]

• What options did you set as part of the installation? Or did you choose the
  defaults?

N/A (portable version)

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

N/A

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• What commands did you run to trigger this issue? If you can provide a Minimal, Complete, and Verifiable example this will help us understand the issue.

git svn fetch

Simply run the above without any saved credentials.

• What did you expect to occur after running these commands?

To be prompted for my SVN password, as in earlier versions.

• What actually happened instead?

Authentication realm: <https://example.com:443> My Subversion Repository
Password for 'User': ReadKey.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xe080080)

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

N/A

[dscho]

Thank you for the report. I will have to recompile perl-TermReadKey, it seems. Will do that as soon as I get a chance.

[dscho]

It is not quite fixed yet, I'll keep you updated as to the progress, and will ask you to test a snapshot installer.

[dscho]

This is finally fixed (I had some problems keeping the Git for Windows SDK working after some unfortunate changes made by MSYS2).

@mehrdadn I would like to ask you to verify that this is indeed fixed by the rebuilding of the perl-TermReadKey package: there is now a snapshot installer with the fix: https://wingit.blob.core.windows.net/files/index.html

[mehrdadn]

Sure, I just tested it. The 64-bit version works now, but the 32-bit version is now broken in a different way:

> "D:\Downloads\PortableGit-prerelease-2.16.1.windows.4.1.gd1a7b3b9ef-32-bit.7z\bin\git" svn fetch
Can't load '/usr/lib/perl5/vendor_perl/auto/SVN/_Core/_Core.dll' for module SVN::_Core: Exec format error at /usr/lib/perl5/core_perl/DynaLoader.pm line 193.
  at /usr/lib/perl5/vendor_perl/SVN/Base.pm line 59.
BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/SVN/Core.pm line 5.
Compilation failed in require at /mingw32/share/perl5/site_perl/Git/SVN/Utils.pm line 6.
BEGIN failed--compilation aborted at /mingw32/share/perl5/site_perl/Git/SVN/Utils.pm line 6.
Compilation failed in require at /mingw32/share/perl5/site_perl/Git/SVN.pm line 32.
BEGIN failed--compilation aborted at /mingw32/share/perl5/site_perl/Git/SVN.pm line 32.
Compilation failed in require at D:\Downloads\PortableGit-prerelease-2.16.1.windows.4.1.gd1a7b3b9ef-32-bit.7z\mingw32/libexec/git-core\git-svn line 21.
BEGIN failed--compilation aborted at D:\Downloads\PortableGit-prerelease-2.16.1.windows.4.1.gd1a7b3b9ef-32-bit.7z\mingw32/libexec/git-core\git-svn line 21.

[dscho]

@mehrdadn thank you for testing it. I did not even think to test 32-bit separately... and sure enough, it fails also on my machine :-(

Will keep you posted.

[dscho]

Okay, that took longer than expected. Sorry about that. I completely chased down the wrong goose: I found out that somehow the Perl process still tried to access msys-perl5_24.dll (wrong version: it should be msys-perl5_26.dll), expected some sort of build problem, even verified that a rebuilt _Core.dll has the same problem (the Perl process still tried to access msys-perl5_24.dll). What I failed to notice is that it was no longer _Core.dll that dragged this dependency in, but msys-svn_swig_perl-1-0.dll (which I had rebuilt, but not replaced in the portable Git).

Had I noticed that, I would have realized that the problem lay completely elsewhere.

Turns out that due to a bug in one of my scripts, the upload of Subversion "succeeded" despite a lock on the 32-bit package database (from a failed previous run) preventing that database from being updated. So the 32-bit snapshot had subversion 1.9.7-2 while the 64-bit had subversion 1.9.7-3.

The fix was obviously to upload the correct subversion package version to the Pacman repository. I also had to check whether other packages were affected, and sure enough: there were. I fixed them, too, of course.

The next snapshot is building (it will have the same Git version number) and should be available within the next twenty minutes or so.

[dscho]

Okay, it's finally built and uploaded: https://wingit.blob.core.windows.net/files/index.html

[mehrdadn]

Yup, it works now! (Assuming I run post-install.bat for 32-bit. On 64-bit it's not required.)

[ashumkin]

I can confirm the fix, too (for 32-bit portable). (I've faced the issue, too, but with some different conditions - I have interactive.singlekey option used with git add --patch)

[dscho]

Yeah! Thank you both for testing!