Re: who is building Octave on Windows systems?

[Benjamin Lindner]

> Is your copy of gnulib up to date?

Yes, I updated before reconfiguring&rebuilding octave

> If so, do you have the problem if
> you run the following in your build tree:
>
>  cd libgnu
>  make maintainer-clean
>  cd ..
>  /path/to/octave/sources/configure ...
>  make

I have to check this, but ...

> Can you send me the libgnu/unistd.h file that is generated when you
> build Octave?  On my system, it begins with

... I think I found the problem. On my system, it begins with

/* Special invocation convention:
   - On mingw, several headers, including <winsock2.h>, include <unistd.h>,
     but we need to ensure that both the system <unistd.h> and <winsock2.h>
     are completely included before we replace gethostname.  */
#if 1 && 1 \
  && !defined _GL_WINSOCK2_H_WITNESS && defined _WINSOCK2_H
/* <unistd.h> is being indirectly included for the first time from
   <winsock2.h>; avoid declaring any overrides.  */
# if 1
#  include_next <unistd.h>
# else
#  error unexpected; report this to address@hidden
# endif
# define _GL_WINSOCK2_H_WITNESS

/* Normal invocation.  */
#elif !defined _GL_UNISTD_H

and the point is, that looking at the preprocessed oct-env.cc,
windows.h is included via pthreads.h via libgnu/time.h via quite a
chain of other headers, which in consequence includes winsock2.h (via
windows.h), which defines the macro _WINSOCK2_H, which now makes the
first #if clause true, and thus skips the entire libgnu/unistd.h
header.
But now _GL_WINSOCK2_H_WITNESS is defined, so on a second inclusion of
libgnu/unistd.h this first #if clause fails, and now the header is
properly preprocessed.

Reordering <unistd.h> to be included first in oct-env.cc as in

diff --git a/liboctave/oct-env.cc b/liboctave/oct-env.cc
--- a/liboctave/oct-env.cc
+++ b/liboctave/oct-env.cc
@@ -40,6 +40,7 @@
 #include <config.h>
 #endif

+#include <unistd.h>
 #include <cctype>
 #include <cstdlib>
 #include <cstring>
@@ -47,7 +48,6 @@
 #include <string>

 #include <sys/types.h>
-#include <unistd.h>

 #include "progname.h"

also solves the problem.

So yes, I'd consider it a bug in gnulib's unistd.h implementation

benjamin