Whoops... this will require a more extensive change to fix the issue.

The error is here

numpy/core/src/multiarray/buffer.c:1085:22: error: expected expression before ‘_Complex’
 1085 |     case 'f': return complex ? NPY_CFLOAT : NPY_FLOAT;
      |                      ^~~~~~~
numpy/core/src/multiarray/buffer.c:1086:22: error: expected expression before ‘_Complex’
 1086 |     case 'd': return complex ? NPY_CDOUBLE : NPY_DOUBLE;
      |                      ^~~~~~~
numpy/core/src/multiarray/buffer.c:1087:40: error: expected ‘)’ before ‘?’ token
 1087 |     case 'g': return native ? (complex ? NPY_CLONGDOUBLE : NPY_LONGDOUBLE) : -1;
      |                               ~        ^
numpy/core/src/multiarray/buffer.c:1087:76: error: expected expression before ‘:’ token
 1087 |     case 'g': return native ? (complex ? NPY_CLONGDOUBLE : NPY_LONGDOUBLE) : -1;

where the source code uses the keyword complex as a variable name

I think there is a also a place in f2py that does the same thing

@mattip, yeah, the f2c code in lapack_lite directory uses the name complex, so building it will break if complex is not undef'd. There are few other places where the name complex is used that break the build if complex is not undef'd. I created an issue about this problem: #24344.

I fixed the uses of complex in the lapack_lite code (files f2c*.[ch] in numpy/linalg/lapack_lite/) and in numpy/core/src/multiarray/buffer.c, and except for an unrelated TravisCI failure, CI passed.

This shows that we can remove #undef complex from npy_common.h and build numpy. If we decide to do that, the current version of this pull request is not the correct way to make the change. I directly edited the C files with the command

sed -i '' "s/\([^e]\)complex/\\1complex_/g" f2c*.c f2c*.h

on my Mac. But those files are supposed to be generated by the python script make_lite.py. Running that script requires Python 2.7. There are also several .patch files in the directory that I haven't looked at too closely--it might just be luck that those patches didn't conflict with the changes I made. In short, the "correct" fix feels like it has the potential to be a can of worms that I'm not too excited to open. Long term, it might be a nice project for someone with an SDG grant or something similar to upgrade the whole system by which lapack_lite is supported--assuming we're not planning on dropping the whole thing some time soon.

Also, if we make the change, we'll break extension modules that happen to use the name complex--or any other name from <complex.h>--in their code. But I think making the change is the correct thing to do. We really shouldn't be changing (in this case, removing) names that are defined in standard library headers.

I think this is the correct path forward. Did we not add a release note in #24085? We should also document the fact that #include <npy_math.h> will now pull in complex.h in the regular developer docs somewhere.

@mattip, @seberg and @rgommers agree that we need to undo the use of #undef complex in npy_common.h, so I added the 2.0.0 milestone to #24344.

This pull request is just the proof of concept; the correct change for the lapack_lite code (probably) involves regenerating the C code and adding new patch files to fix the use of complex. I don't think I'll have time in the immediate future to dig into that, so I'm closing this PR.