emacs-devel
[Top][All Lists]
Advanced

[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).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]