Re: who is building Octave on Windows systems?

[John W. Eaton]

On 26-Jan-2011, Benjamin Lindner wrote:

| > 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

Will you please send this info to the address@hidden list?

Thanks,

jwe