This is the mail archive of the
mailing list for the Cygwin project.
Re: git stopped working with 1.7.1
- From: Jeremy Bopp <jeremy at bopp dot net>
- To: cygwin at cygwin dot com
- Date: Wed, 07 Apr 2010 09:19:31 -0500
- Subject: Re: git stopped working with 1.7.1
- References: <firstname.lastname@example.org> <email@example.com> <4B5D7DDF.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On 4/7/2010 5:12 AM, nothize wrote:
> After I've replaced(or removed!) %windir%\system32\cygz.dll with the newer
> one in Cygwin, git 184.108.40.206 worked well. Perhaps I've manually copied an
> older cygz.dll to there sometimes ago.....I can't remember.
The Cygwin setup program never installs files into system32. You most
likely have some other piece of software which embedded Cygwin and
helpfully broke your general Cygwin installation by installing Cygwin
DLLs to system32 for you. If you want to have a functional Cygwin
installation, you would be better off removing the offending software
and ensuring that all Cygwin DLLs are removed from system32.
> Note that I have the registry value to allow "loading DLL from the same
> directory preceding the path" but %windir%\system32 is always the first in
> the PATH environment variable.
This is a well-documented behavior of Windows:
Many of the git subcommands now live in /usr/lib/git-core, so none of
the Cygwin DLLs exist in the same directory as the subcommand binaries.
If SafeDllSearchMode is disabled, the current directory is searched
next, but no one is likely to have copies of Cygwin DLLs in every
directory in which they may be running commands. The next fallback in
both safe and non-safe mode is the system directory (system32). When
the matching DLL is found there, it preempts the use of the DLL you
intended to find via PATH.
This is why it is BAD, BAD, BAD to install third-party DLLs into
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple