[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues with Windows gcc -mno-cygwin (Mingw)
From: |
Eli Zaretskii |
Subject: |
Re: Issues with Windows gcc -mno-cygwin (Mingw) |
Date: |
Tue, 18 Mar 2003 19:54:57 +0200 |
> From: Benjamin Riefenstahl <address@hidden>
> Date: 18 Mar 2003 18:14:09 +0100
>
> I have compiled the CVS HEAD with the Cygwin Mingw cross-environment
> (gcc -mno-cygwin). I have had two problems:
>
> - The cygpath issue. The Makefiles have the necessary code to use the
> Cygwin cygpath utility, but it's commented out. I appreciate that
> the situation is not very stable in that area, but could we consider
> a conditional and a configure item for this? We do need that code
> as long as we want Emacs to support Cygwin at compile-time, but not
> at run-time, because without that code the Makefile will provide
> Cygwin paths to ELisp.
Could you please be more specific? Where in ELisp will Cygwin paths
be inserted?
> - Problem with _fmode (global MSC variable set to O_BINARY as the
> default file mode). For a simple patch see below. Strictly
> speaking I think the real problem is that this is not handled
> without the _fmode hack. The code should just use its own global
> variable (or even more simply just add O_BINARY everywhere) instead
> of using this brittle compiler/runtime dependent solution.
Is this change only for the unexec phase, or for the entire Emacs
operation? If the former, you could use O_BINARY in unexw32.c and be
done with it. If the latter (which I suspect is the case), emacs.c
already has similar code fragments for other DOS/Windows ports, so I
think the MinGW port should also use it (I actually thought it already
did, so I wonder how come this was a problem in your case).