The procedure entry point curl_global_sslset could not be located in the dynamic link library libcurl-4.dll.

[brechtm]

• 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?

mingw-w64-x86_64-git-2.14.1.1.82d9b3f3b2-1 from the git-for-windows pacman repository.

$ git --version --build-options

git version 2.14.1.windows.1
built from commit: 82d9b3f3b2407b52251620597d4b14933685459d
sizeof-long: 4
machine: x86_64

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

Windows 7 Enterprise SP1

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

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

I installed mingw-w64-x86_64-git in MSYS2.

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

I'm running git-for-windows inside an MSYS2 installation as described here: https://stackoverflow.com/questions/40262434/what-are-the-differences-between-msys-git-and-git-for-windows-mingw-w64-x86-64-g

This was working well with previous versions of git-for-windows, up to and including mingw-w64-x86_64-git-2.13.2.1.914b84c9d9-1 (to which I've reverted for now). I am aware that this non-standard setup may be causing the crash.

Details

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

Bash and 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 fetch

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

A non-zero return code.

• What actually happened instead?

Bash: a return code of 128. No output or pop-up.
CMD: A pop-up dialog:

---------------------------
git-remote-ftp.exe - Entry Point Not Found
---------------------------
The procedure entry point curl_global_sslset could not be located in the dynamic link library libcurl-4.dll. 
---------------------------
OK   
---------------------------

[dscho]

Duplicate of #1268 (please really search existing tickets when asked to). You need to uninstall Gt completely and make sure C:\Program Files\Git was removed before reinstalling.

[brechtm]

I did inspect that issue. The error message is different. Plus I did not install Git using the installer but into MSYS2 using pacman.

[dscho]

If you install Git for Windows' Pacman package into MSYS2 without Git for Windows' other support packages, of course things break. That is to be expected. If you don't know the ramifications of what you did, it'd be better to stick with Git for Windows SDK instead.

[brechtm]

I understand this is not a supported way of installing git-for-windows. However, it was working without issues before. I'm trying to understand what changed since 2.13.2.1.914b84c9d9-1 to cause this.

[dscho]

@brechtm I am sympathetic to your reasoning. Please note, however, that I am not exactly in need for even more work, and you are putting more work on my shoulders.

The reason why you see this error is that I use an experimental cURL version in Git for Windows that has curl/curl#1601 integrated. This cURL version is not available in MSYS2, unless you install it specifically from Git for Windows' Pacman repository.

Of course, you can work around the reported issue by doing exactly as I said. The problem is that next time something similar happens, you will most likely have as little idea what happened as now because you are inactive in Git for Windows' development and therefore miss all the recent developments, so you will have to ask again, and I will have to set aside time again to address your problem, leaving other problems (that affect more than a single user) behind.

[brechtm]

Thanks @dscho. I appreciate you took the time to explain the cause of this crash. I can imagine you have enough work as it is, so I do not expect you to support this non-standard installation. So please do not feel obliged to spend time on this or similar tickets. I can live with an answer like "This is not a supported usage scenario for git-for-windows. I cannot afford to spend time investigating this issue". And this is basically all I can expect, seeing that you are doing this free of charge. Besides hoping for an answer to my question, I do think this ticket could be useful to others (however few) who run into the same problem.

Ideally, I would be using the git provided in the MSYS2 repository, but it suffers from some problems (detailed in the StackOverflow question I linked to above).

In any case, thanks for bringing a very useful piece of software to the Windows platform!

[brechtm]

Putting the git-for-windows and git-for-windows-mingw32 sections above the others as in the SDK's etc/pacman.conf seems to install the proper version of libcurl, making git work again.

[dscho]

@brechtm you are turning your MSYS2 installation into a Git for Windows SDK. The hard way. Probably you also want to install the git-extra package now, to fix up things in MSYS2 that are still incorrect.

[mishrsud]

Thanks @dscho, your tip to uninstall and reinstall git for windows worked perfectly. I was starting to lose my mind trying to figure out why I got the error message in the title of this thread after upgrading to "git version 2.14.1.windows.1"

[brechtm]

@dscho I can't remember why I opted for MSYS2 + the git-for-windows repository instead of the Git for Windows SDK. I suppose the SDK acts pretty much identical to MSYS2 with the exception of git, such as having the ability to upgrade packages using pacman? I'll replace MSYS2 with the SDK then if I run into any issues in the future.

[dscho]

@brechtm Git for Windows' SDK is nothing else than a special edition of MSYS2, indeed. As you found out, it adds (actually, prepends) two Pacman repositories, and it also installs the git-extra package which does a ton of modifications in its post install script to change things in MSYS2 that cannot be configured otherwise (such as patching a couple of overzealous commands in Bash's profile).

[Youda008]

This is not an issue of a single user. There is a good reason, why many of us would like to use git package in original msys2 instead of Git-For-Windows. Not all users want to have msys2 environment just for git and nothing else (which is what Git-For-Windows does), and it doesn't make sense to have 2 instances of msys2, first the original one with all the other packages and second one specialized only for git, packed together in Git-For-Windows. Then you can't the other Unix tools in Git-bash, because they are installed in the other msys2.

[dscho]

@Youda008 I have a lot of sympathy for your desire.

And I would have even more sympathy (a metric ton, if you want) if y'all started to work on making that use case easier not only for yourself, but for others, too.

[charlieok]

Commenting to weigh in on the relevance of the discussion here to many users vs few.

I didn't land here due to hitting an error. Instead I'm just trying to learn how to set up a windows environment, coming from *nix with the mandate to work on building an app on windows, and having been away from the windows world for a long time.

A series of realizations proceeded something like the following:

• Like with most software projects today, it's a given that I will need git

• there is a special git distribution specifically for windows. Unlike git for every other platform, a bunch of other unixy tools come bundled along with it. It even appears to have its own separate shell and/or terminal for some reason

• our app, like many, has its own system of makefiles and build scripts developed in unix-like environments, so it relies on tools and filesystem paths that belong to that world. Among them are autotools, gcc, make etc.

• some work has gone into making cross-compilation to windows work using mingw on linux, so now there's interest in building it using mingw on windows.

• After some reading, it appears that msys is exactly the thing for this. A unix-like environment (forked from cygwin) with the specific goal of helping build projects in the category I've described using the mingw toolchain on windows.

• Actually upon some more reading people are saying msys is poorly maintained and msys2 is a more up to date project with essentially the same purpose.

• msys2 includes its own package manager (pacman ported from arch linux) and multiple separate environments, each with their own pacman repositories, for combinations of (32bit and 64bit) and (posix-emulated and windows native) binaries. The set of packages offered in these repositories is limited as compared with cygwin (a more general-purpose posix environment) to software relevant to compiling things for windows, but includes git packages, since git falls in that category.

• msys2 is actually bundled with git for windows. That is what that unix stuff that comes with git for windows is.

• So to recap there is:

  • an official git for windows release that includes msys2 (and optionally lets you add the msys2 stuff to your system PATH but comes with warnings about doing that)
  • an official msys2 release that has git packages for its various environments.

What combination of things is a developer likely to want in order to work on their own project? Reading about problems with the git package for msys2 seems to point toward eschewing that and installing git for windows. In the comments here, the result of taking the git for windows route is described as a "Git for Windows SDK" which sounds like something with the narrow purpose of working on git for windows itself. Also in the comments here, mixing and matching seems to be frowned upon.

My main purpose in following the trail that led me through here is to resolve the confusion about how to properly set up a mingw dev environment in windows. Any helpful pointers toward that end are much appreciated. But please nobody take this as a demand for time you don't have.

[dscho]

@charlieok here are my 2 cents:

It is important to know the history so that you understand the different terms being thrown around. First of all, there is a distinction between MSYS and MINGW: MSYS comes with a POSIX emulation layer (based on Cygwin), allowing you to build Linux/Unix software changing very little if anything in the source code. MINGW, on the other hand, targets the Win32 API, it does not guarantee you the full POSIX functionality (most notable, the fork() call is not supported in MINGW, nor can you use socket functionality via plain file descriptors). Of course, the POSIX emulation comes at the penalty of a substantially reduced execution speed: MSYS software is slow compared to their MINGW counterparts, when those exist.

Also, there are the occasional hiccups with the POSIX emulation.

The MSYS and MINGW systems come both with their entire toolchain: a gcc, libraries, headers, everything. You cannot mix and match between them, not without running into serious troubles sooner or later. You have to decide whether you want to save on development time, or whether you want your software be as native to Windows as possible. With Git for Windows, we chose the latter.

And it is true that MSys/MINGW are not supported very well, they've fallen behind (no 64-bit, no Unicode, etc). MSYS2 is really the way forward in that respect.

In contrast, MSYS2 is maintained very actively, and their MINGW packages are based on the equally active mingw-w64 project.

Your assumption that Git for Windows comes with MSYS2 is only partially correct: due to the original design (which was not that smart, in hindsight), Git is implemented partially as Perl/Unix shell scripts, so we need something to run them. For that reason, we bundle some files from MSYS2. Git for Windows (as in: the end-user facing installer) never aimed, and never will aim, to include a full-fledged MSYS2.

As to your question what is the smartest way to develop MINGW software: my answer would be to use MSYS2 in its default MINGW mode.

But maybe an even smarter thing would be to ask this question not attached to a pretty unrelated bug report. I would suggest the StackOverflow...

[charlieok]

Thank you @dscho ! Very helpful. I apologize for posting the question here. I queued up a lot of things to read, and have gotten around halfway through them, but had some burning questions after reading through the thread here. Before I'm done I'll probably have scattered some more questions elsewhere.

I think my takeaway here though is that for an msys2/mingw environment, I probably just want the git package within that environment, while git for windows is for people who are not working within that type of environment.