From: Rogan Dawes Date: Fri, 20 Mar 2009 13:49:50 GMT Subject: Re: [PATCH] Define a version of lstat(2) with posix semantics Message-ID: <49C39EFE.8040507@dawes.za.net> In-Reply-To: <81b0412b0903200639v6d99067csb7715d9a5a3f0ba4@mail.gmail.com> Alex Riesen wrote: > 2009/3/20 Johannes Schindelin : >> On Fri, 20 Mar 2009, Alex Riesen wrote: >> >>> 2009/3/20 Johannes Schindelin : >>>> Now, we _do_ have msysGit, you _do_ have shown the capability to fix >>>> issues when they arise, so I do _not_ see any obstacle why you should >>>> not go msysGit, rather than staying with the pain of trying to stay >>>> POSIX-compatible, but not quite all the time. >>> I understand. It is not pure POSIX compatibility I seek. I just can't >>> use MinGW port, because I absolutely must use the cygwin environment >>> (for "hysterical" reasons) and they don't play well together (tried, >>> yes. Conflicting libraries, but you already know that). >> Maybe we can work on those conflicting libraries? After all, we do have a >> "rebase.exe" tool now (for all those as puzzled by the naming as I was: >> the rebase.exe tool can shift the memory range used by a .dll so that it >> does not overlap with that one of another .dll). > > As long as they can be made to coexist I'm fine. Wasn't the problem > that MinGW/MSYS used cygwin1.dll if it were in PATH? Or was it > something else with their supporting libraries? > > My other problem is that the cygwin programs, and the worst of all - a > proprietary compiler based on cygwin, must be in PATH. AFAIR, the > presence of cygwin in PATH broken shell scripting. How about a wrapper that fixes the PATH before exec'ing git? i.e. removes cygwin and the compiler. Rogan