cygwin-minimal, cygwin-standard: scipy build fails: 'u_int' has not been declared

[Matthias Köppe]

​https://github.com/mkoeppe/sage/runs/1153050152

In file included from /usr/include/sys/config.h:5,
                   from /usr/include/_ansi.h:11,
                   from /usr/include/sys/reent.h:13,
                   from /usr/include/math.h:5,
                   from /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/cmath:45,
                   from scipy/spatial/ckdtree/src/query.cxx:1:
  /usr/include/sys/features.h:255: note: this is the location of the previous definition
    255 | #define __BSD_VISIBLE  0
        |
  In file included from /cygdrive/d/a/sage/sage/local/include/python3.8/pyport.h:219,
                   from /cygdrive/d/a/sage/sage/local/include/python3.8/Python.h:63,
                   from /cygdrive/d/a/sage/sage/local/lib/python3.8/site-packages/numpy/core/include/numpy/npy_common.h:11,
                   from scipy/spatial/ckdtree/src/ckdtree_decl.h:10,
                   from scipy/spatial/ckdtree/src/query.cxx:13:
  /usr/include/sys/time.h:106:34: error: 'u_int' has not been declared
    106 | bintime_mul(struct bintime *_bt, u_int _x)
        |                                  ^~~~~
  g++: scipy/spatial/ckdtree/src/build.cxx

Also seen in cygwin-standard (​https://github.com/sagemath/sage/runs/1190880811)

Blocker for 9.2 because it is a regression in platform support

[Matthias Köppe]

This build problem that we see on the CI infrastructure could use help from a real Cygwin user

[Volker Braun]

Possibly relevant: ​https://stackoverflow.com/questions/39786845/cygwin-g-compiling-with-python-h-duplicated-definition-of-bsd-visible

[Erik Bray]

What Cygwin version is it using? This might be a newly introduced issue in one of Cygwin's libc headers.

I'm still on an older version that doesn't have this problem:

$ uname -a
CYGWIN_NT-10.0 <Hostname> 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin

[Erik Bray]

I've seen issues like this before. The problem is visible in this line from the log:

  [scipy-1.5.2]     error: Command "g++ -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -I/cygdrive/d/a/sage/sage/local/include/python3.8 -I/cygdrive/d/a/sage/sage/local/lib/python3.8/site-packages/numpy/core/include -Iscipy/_lib -Iscipy/_build_utils/src -Iscipy/spatial/ckdtree/src -I/cygdrive/d/a/sage/sage/local/lib/python3.8/site-packages/numpy/core/include -I/cygdrive/d/a/sage/sage/local/include/python3.8 -c scipy/spatial/ckdtree/src/query.cxx -o build/temp.cygwin-3.1.7-x86_64-3.8/scipy/spatial/ckdtree/src/query.o -MMD -MF build/temp.cygwin-3.1.7-x86_64-3.8/scipy/spatial/ckdtree/src/query.o.d -std=c++14" failed with exit status 1

In Cygwin's libc, __BSD_VISIBLE = 0 by default, because when using -std=c[++]<nn> flags it defined __STRICT_ANSI__ and non-ANSI C extensions are not declared as you can see with the following test program:

$ cat bsd_visible.c
#include <stdio.h>
#include <sys/features.h>

#if defined(__STRICT_ANSI__)
#define DEFINED__STRICT_ANSI__ 1
#else
#define DEFINED__STRICT_ANSI__ 0
#endif

int main(void) {
    printf("defined(__STRICT_ANSI__) = %d\n", DEFINED__STRICT_ANSI__);
    printf("__BSD_VISIBLE = %d\n", __BSD_VISIBLE);
    return 0;
}

$ g++ -std=c++14 bsd_visible.c -o bsd_visible
$ ./bsd_visible.exe
defined(__STRICT_ANSI__) = 1
__BSD_VISIBLE = 0

However, if you compile with -std=gnu[++]<nn> the "kitchen sink" is enabled:

$ g++ -std=gnu++14 bsd_visible.c -o bsd_visible
$ ./bsd_visible.exe
defined(__STRICT_ANSI__) = 0
__BSD_VISIBLE = 1

You can also work around this by defining the _GNU_SOURCE macro e.g. when building SciPy?. This might be the easiest workaround:

$ g++ -std=c++14 -D_GNU_SOURCE bsd_visible.c -o bsd_visible
$ ./bsd_visible.exe
defined(__STRICT_ANSI__) = 1
__BSD_VISIBLE = 1

[Matthias Köppe]

Replying to embray:

What Cygwin version is it using? This might be a newly introduced issue in one of Cygwin's libc headers.

The GH runs always use the most current version. I was not able to reproduce the error on my Windows 10 tablet (both with Cygwin 3.1.4 and after upgrading to the current 3.1.7). So whether the error shows up seems to depend in a subtle way on the list of Cygwin packages installed. I'm investigating this at the moment.

[Erik Bray]

It would most likely be caused by something that changed in newlib. I can't see any obvious culprits in the the history. But in fact it seems like what was changed was actually fixing something that shouldn't have worked in the first place. Once of the workarounds I suggested above should be used.

[Matthias Köppe]

Replying to embray:

You can also work around this by defining the _GNU_SOURCE macro e.g. when building SciPy?. This might be the easiest workaround:

$ g++ -std=c++14 -D_GNU_SOURCE bsd_visible.c -o bsd_visible
$ ./bsd_visible.exe
defined(__STRICT_ANSI__) = 1
__BSD_VISIBLE = 1

Thanks a lot. I'm trying this solution now. Let's see how this goes.

---

New commits:

​454308f

build/pkgs/{numpy,scipy} [Cygwin]: Define _GNU_SOURCE

[Matthias Köppe]

This seems to have done the trick. See ​https://github.com/mkoeppe/sage/runs/1250401299?check_suite_focus=true

[Erik Bray]

Great!