BLD: remove /usr/include from default include dirs

[rgommers]

Including this directory is painful for cross-compiling, see gh-14980 and gh-13280. Removing this directory fixes the following build failure:

gcc: numpy/core/src/common/numpyos.c
In file included from numpy/core/src/common/numpyos.c:23:
/usr/include/xlocale.h:27:16: error: redefinition of ‘struct __locale_struct’
   27 | typedef struct __locale_struct

This error also shows up in various other build issues outside of the NumPy issue tracker.

Compilers normally always include this path, so this shouldn't break anything. The default include paths for the compiler can be checked, e.g. for gcc with cpp -v. That will typically have /usr/include last.

In case this breaks something for a nonstandard compiler, that can be worked around via a site.cfg file in the root of the repo (or equivalently, ~/numpy-site.cfg) containing:

[DEFAULT]
include_dirs = /usr/include

The same principle should apply to /usr/lib. The /usr/lib change is made in a separate commit, because the failure mode for that will be different (may be useful in case this breaks something else).

EDIT: to clarify: it is not possible to fix this with an extra ifdef in numpyos.c, the problem is that there's a mix between locale.h and xlocale.h that both exist but are not compatible. For example, a really new locale.h in /usr/include on Arch Linux, combined with an old xlocale.h shipped with conda.

EDIT2: currently it's really easy to reproduce the xlocale.h failure:

• On Arch Linux, create a fresh conda environment with the environment.yml in DEV: add a conda environment.yml with all development dependencies #18659
• Activate the environment and run python setup.py build_ext -i.

[rgommers]

The blas64 job ends with:

  numpy.distutils.system_info.BlasILP64NotFoundError:
      64-bit Blas libraries not found.
      Known libraries in numpy/distutils/site.cfg file are:
      openblas64_, openblas_ilp64

and on Shippable with:

  python tools/openblas_support.py --check_version
Traceback (most recent call last):
  File "tools/openblas_support.py", line 331, in <module>
    test_version(args.check_version)
  File "tools/openblas_support.py", line 303, in test_version
    get_config = dll.openblas_get_config
  File "/usr/lib/python3.7/ctypes/__init__.py", line 369, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 374, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /root/venv/3.7/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-aarch64-linux-gnu.so: undefined symbol: openblas_get_config

So that seems to need /usr/lib

[charris]

The two github actions failure both use blas64.

[rgommers]

The design of tools/openblas_support.py is a bit clumsy - it unpacks the openblas libraries to a directory that is encoded within the .tar.gz itself. Some debug printing says it ends up in /tmp/openblas/lib/libopenblas64_.a, but somehow removing /usr/lib is problematic.

I'll just remove the second commit, we can deal with /usr/lib later if needed. SciPy also has the same openblas_support.py, and it's not worth the effort to change it right now.

[charris]

Thanks Ralf.

[rgommers]

Thanks Chuck. This needs a release note too, sending a follow-up PR now.