MinGW build broken with O_CLOEXEC undeclared

MinGW build broken with O_CLOEXEC undeclared

[martin rudalics]

Compiling master is currently broken on my Windows XP (MinGW gcc 4.8.1) as below

../../lib/futimens.c:31:1: warning: no previous prototype for 'futimens' [-Wmissing-prototypes]
  futimens (int fd, struct timespec const times[2])
  ^
   CC       getopt1.o
   CC       gettimeofday.o
   CC       memmem.o
   CC       mempcpy.o
   CC       memrchr.o
   CC       mkostemp.o
   CC       mktime.o
   CC       open.o
../../lib/open.c: In function 'sys_open':
../../lib/open.c:127:49: error: 'O_CLOEXEC' undeclared (first use in this function)
                    flags & ~(have_cloexec <= 0 ? O_CLOEXEC : 0), mode);
                                                  ^
../../lib/open.c:127:49: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [open.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
make: *** [lib] Error 2

martin

Re: MinGW build broken with O_CLOEXEC undeclared

[Paul Eggert]

On 3/8/20 12:53 AM, martin rudalics wrote:
> Compiling master is currently broken on my Windows XP (MinGW gcc 4.8.1) as below
> 
> ../../lib/futimens.c:31:1: warning: no previous prototype for 'futimens' 
> [-Wmissing-prototypes]
>   futimens (int fd, struct timespec const times[2])

Yes, I assume this is a consequence of the patch for Bug#39773 being installed.
The MinGW port will need to make sure that futimens and utimensat work, 
presumably by breaking apart fdutimens (which is no longer needed).

> ../../lib/open.c:127:49: error: 'O_CLOEXEC' undeclared (first use in this function) 

Did the MinGW port formerly compile open.c? If so, why is O_CLOEXEC undeclared 
now when it was declared formerly? If not, why is the MinGW port compiling 
open.c now?

Re: MinGW build broken with O_CLOEXEC undeclared

[martin rudalics]

 > Did the MinGW port formerly compile open.c?

No, AFAICT (on the release branch it doesn't).

 > If not, why is the MinGW port compiling open.c now?

How would I find out?  From config.log I can only tell that

gl_GNULIB_ENABLED_cloexec='1'
...
gl_GNULIB_ENABLED_open='1'
...
gl_GNULIB_ENABLED_utimens='1'

are enabled now (and aren't on release builds).

martin

Re: MinGW build broken with O_CLOEXEC undeclared

[Paul Eggert]

On 3/8/20 1:34 AM, martin rudalics wrote:
>  > Did the MinGW port formerly compile open.c?
> 
> No, AFAICT (on the release branch it doesn't).

It's not an issue of the master vs the release branch; it's an issue of before 
and after commit 5d4cf1fef85bc24bc4cd9705ebb14150263ad707, which added the 
nofollow flag to set-file-times.

>> If not, why is the MinGW port compiling open.c now?
> 
> How would I find out?

Find out why the 'configure' script is executing 'REPLACE_OPEN=1' now, when it 
didn't do it before that commit. You may need to put some debugging commands 
into it, e.g., 'echo "got to here" >>/tmp/log'.

Re: MinGW build broken with O_CLOEXEC undeclared

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 8 Mar 2020 09:53:54 +0100
> Cc: Paul Eggert <eggert@cs.ucla.edu>
> 
> Compiling master is currently broken on my Windows XP (MinGW gcc 4.8.1) as below
> 
> ../../lib/futimens.c:31:1: warning: no previous prototype for 'futimens' [-Wmissing-prototypes]
>   futimens (int fd, struct timespec const times[2])
>   ^
>    CC       getopt1.o
>    CC       gettimeofday.o
>    CC       memmem.o
>    CC       mempcpy.o
>    CC       memrchr.o
>    CC       mkostemp.o
>    CC       mktime.o
>    CC       open.o
> ../../lib/open.c: In function 'sys_open':
> ../../lib/open.c:127:49: error: 'O_CLOEXEC' undeclared (first use in this function)
>                     flags & ~(have_cloexec <= 0 ? O_CLOEXEC : 0), mode);
>                                                   ^
> ../../lib/open.c:127:49: note: each undeclared identifier is reported only once for each function it appears in
> make[1]: *** [open.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
> make: *** [lib] Error 2

Should be fixed now.

For cleaner results, I suggest to do the following after "git pull"
and before saying "make":

  $ rm lib/*.[oa]
  $ touch configure.ac lib/gnulib.mk.in

Re: MinGW build broken with O_CLOEXEC undeclared

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 8 Mar 2020 03:08:05 -0700
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> >> If not, why is the MinGW port compiling open.c now?
> > 
> > How would I find out?
> 
> Find out why the 'configure' script is executing 'REPLACE_OPEN=1' now, when it 
> didn't do it before that commit. You may need to put some debugging commands 
> into it, e.g., 'echo "got to here" >>/tmp/log'.

lib/open.c is not supposed to be compiled in the MinGW build.

Re: MinGW build broken with O_CLOEXEC undeclared

[martin rudalics]

 > Should be fixed now.

Thanks.

 > For cleaner results, I suggest to do the following after "git pull"
 > and before saying "make":
 >
 >    $ rm lib/*.[oa]
 >    $ touch configure.ac lib/gnulib.mk.in

This doesn't seem to work.  Doing that right after a "git pull" triggers
automatic reconfigure (takes ages here).  And after that building fails as

...
make info-real info-dir
make[1]: Entering directory `/c/emacs-git/trunk/dbg/lib'
Makefile:39: *** Recursive variable `am__v_CC_' references itself (eventually).  Stop.
make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
make: *** [lib] Error 2
make: *** Waiting for unfinished jobs....
make[1]: Entering directory `/c/emacs-git/trunk/dbg'
make -C doc/lispref info


If I run your two commands right before "make" it builds normally.

martin

Re: MinGW build broken with O_CLOEXEC undeclared

[Eli Zaretskii]

> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 8 Mar 2020 17:38:29 +0100
> 
>  > For cleaner results, I suggest to do the following after "git pull"
>  > and before saying "make":
>  >
>  >    $ rm lib/*.[oa]
>  >    $ touch configure.ac lib/gnulib.mk.in
> 
> This doesn't seem to work.  Doing that right after a "git pull" triggers
> automatic reconfigure (takes ages here).  And after that building fails as
> 
> ...
> make info-real info-dir
> make[1]: Entering directory `/c/emacs-git/trunk/dbg/lib'
> Makefile:39: *** Recursive variable `am__v_CC_' references itself (eventually).  Stop.
> make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
> make: *** [lib] Error 2
> make: *** Waiting for unfinished jobs....
> make[1]: Entering directory `/c/emacs-git/trunk/dbg'
> make -C doc/lispref info
> 
> 
> If I run your two commands right before "make" it builds normally.

That's what I said: run those before saying "make".  You _must_ force
configure re-run, because some of the files I changed affect how Emacs
is configured.

Are you saying that you still run autogen.sh and configure by hand,
and only after that run "make"?  That's unnecessary.

Or maybe you are building outside of the source tree?  In that case, I
don't know what you should do.

Re: MinGW build broken with O_CLOEXEC undeclared

[Eli Zaretskii]

> Date: Sun, 08 Mar 2020 19:04:49 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> > From: martin rudalics <rudalics@gmx.at>
> > Date: Sun, 8 Mar 2020 17:38:29 +0100
> > 
> >  > For cleaner results, I suggest to do the following after "git pull"
> >  > and before saying "make":
> >  >
> >  >    $ rm lib/*.[oa]
> >  >    $ touch configure.ac lib/gnulib.mk.in
> > 
> > This doesn't seem to work.  Doing that right after a "git pull" triggers
> > automatic reconfigure (takes ages here).  And after that building fails as
> > 
> > ...
> > make info-real info-dir
> > make[1]: Entering directory `/c/emacs-git/trunk/dbg/lib'
> > Makefile:39: *** Recursive variable `am__v_CC_' references itself (eventually).  Stop.
> > make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
> > make: *** [lib] Error 2
> > make: *** Waiting for unfinished jobs....
> > make[1]: Entering directory `/c/emacs-git/trunk/dbg'
> > make -C doc/lispref info
> > 
> > 
> > If I run your two commands right before "make" it builds normally.
> 
> That's what I said: run those before saying "make".

Oh, maybe you understood what I wrote to mean run those two commands
_both_ after "git pull" and before "make"?  If so, sorry for confusing
language: I meant only once, before "make".

Re: MinGW build broken with O_CLOEXEC undeclared

[martin rudalics]

 >> If I run your two commands right before "make" it builds normally.
 >
 > That's what I said: run those before saying "make".

Hmm...  that's what I tried to do.  I did "git pull" and then ran the
two commands.  The subsequent "make" triggered the "configure" and the
following implied "make" failed as indicated.

 > You _must_ force
 > configure re-run, because some of the files I changed affect how Emacs
 > is configured.
 >
 > Are you saying that you still run autogen.sh and configure by hand,
 > and only after that run "make"?  That's unnecessary.

I occasionally do that when "make" fails for some reason.  But not in
the scenario you proposed.

 > Or maybe you are building outside of the source tree?  In that case, I
 > don't know what you should do.

I _am_ building out of the source tree.  How else could I obtain my -O3
build on Windows I need for daily work and a -O0 build for debugging or
my >= 7 toolkit builds on GNU/Linux?

martin

Re: MinGW build broken with O_CLOEXEC undeclared

[Paul Eggert]

On 3/8/20 10:21 AM, martin rudalics wrote:
>  > Or maybe you are building outside of the source tree?  In that case, I
>  > don't know what you should do.
> 
> I _am_ building out of the source tree.  How else could I obtain my -O3
> build on Windows I need for daily work and a -O0 build for debugging or
> my >= 7 toolkit builds on GNU/Linux?

Can you fix the problem by removing your build tree, and then creating an empty 
directory and running '../emacs/configure ...' again?

> make info-real info-dir
> make[1]: Entering directory `/c/emacs-git/trunk/dbg/lib'
> Makefile:39: *** Recursive variable `am__v_CC_' references itself (eventually).  Stop. 

You might be able to work around this via 'make AM_DEFAULT_VERBOSITY=1'. 
However, this would likely be treating the symptom not the problem.

Re: MinGW build broken with O_CLOEXEC undeclared

[martin rudalics]

 > Oh, maybe you understood what I wrote to mean run those two commands
 > _both_ after "git pull" and before "make"?  If so, sorry for confusing
 > language: I meant only once, before "make".

I did it once only - the sequence was

git pull
rm lib/*.[oa]
touch configure.ac lib/gnulib.mk.in
make

But I did the "rm" in the build directory and the "touch" in the source
directory and there is also a gnulib.mk.in in the build directory (not
on GNU/Linux BTW).  Could that have had any impact?

martin

Re: MinGW build broken with O_CLOEXEC undeclared

[martin rudalics]

 > Can you fix the problem by removing your build tree, and then creating an empty directory and running '../emacs/configure ...' again?

Yes.  It's apparently the only way to get rid of it.

martin