Re: [PATCH] Define a version of lstat(2) with posix semantics

From: Alex Riesen <raa.lkml@gmail.com>
Date: Mar 20, 2009, 13:39 UTC
Message-ID: <81b0412b0903200639v6d99067csb7715d9a5a3f0ba4@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0903201015270.10279@pacific.mpi-cbg.de>

2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

Show 17 quoted lines

> On Fri, 20 Mar 2009, Alex Riesen wrote:
>
>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > 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.