emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latest EMACS on BZR trunk does not compile with MinGW


From: Eli Zaretskii
Subject: Re: Latest EMACS on BZR trunk does not compile with MinGW
Date: Thu, 05 Jun 2014 20:52:57 +0300

> From: Óscar Fuentes <address@hidden>
> Date: Thu, 05 Jun 2014 18:19:11 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> Why not test if the preprocessor defines __MINGW32__?
> >
> > How will you call the compiler?  Its exact name and directory isn't
> > known until much later in the script.
> 
> The build failure came from the configure script deciding something
> about dup2 based on MSYSTEM.

No, dup2 is only a tip of an iceberg.  When MSYSTEM is not defined,
the configure script will not source nt/mingw-cfg.site, and quite a
few other things will become broken/flawed in the resulting binary.

nt/mingw-cfg.site is our way of augmenting the configure script in a
way that keeps most of the gory details out of sight of most of the
maintainers, who don't want to know too much about MinGW-specific
quirks.

> That sounds wrong to me: the characteristics of a function are
> supposed to be decided based on specific tests. That means that when
> dup2 is probed by the configure script the test code should detect
> that we are using the MS C runtime and return an specific code.

Most of the configure-time tests indeed do that.  But this particular
test, and a few others, don't, because Emacs on Windows has special
needs that are provided in Emacs's own sources; the configure script
cannot possibly know about that, because it only probes system headers
and libraries.  One such other example is the ACL-related primitives,
which are coded entirely in w32.c; symlink support is yet another.  In
these cases, we force the configure script to make the correct
decision by setting select shell variables to known values in
mingw-cfg.site.

> Is MSYSTEM relevant for anything that must be deciced before we can
> invoke the compiler?

See above.  Better yet, just read configure.ac where it tests for that
variable, and then take it from there.  It's really not so complicated.

> > Perhaps we should only worry about detecting that MSYSTEM isn't set
> > when it should be.  For that, we can wait until the script figures out
> > how to invoke the compiler, and _then_ see if the preprocessor defines
> > __MINGW32__.  If it does, but MSYSTEM is not set, we display an error
> > message and exit.  I think this should be enough; valid MSYS
> > installation should read /etc/profile and then they will have MSYSTEM
> > defined.
> 
> Something like this would be good too, but please note that MSYSTEM can
> be defined with a wrong value. My build failure came from starting MSYS2
> with the wrong script, the one that defines MSYSTEM to "MSYS".

I know nothing about MSYS2; please consider providing the necessary
details so some of them could be added to nt/INSTALL.  I did add there
text that tells how to invoke the MSYS Bash to avoid this problem.




reply via email to

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