BUG: Regression on glibc=2.17 for complex arctanh signbit

[mbargull]

Describe the issue:

At conda-forge, on the numba feedstock we encountered a regression for glibc=2.17 via numba's test suite.
See conda-forge/numba-feedstock#128 (comment) .
Essentially, for 1.26.0, arctanh(-i) gives a "positive zero" real part -- consistent with what catanh from glibc=2.17, but different from NumPy's own implementation and catanh from glibc>2.17.

I tracked that down to be related to builds via meson, i.e., the current 1.26 but also 1.25 show the same behavior if built via meson.
I don't know why the meson-based builds show that behavior.

As expected by the observed behavior, one can see that the extension modules link to glibc's versions (not just catanh, but that is our example here):
readelf --dyn-syms 'numpy/linalg/_umath_linalg.cpython-311-x86_64-linux-gnu.so' | grep -o '[^ ]*catanh[^ ]*':

• for with_meson == "yes":

  catanhf@GLIBC_2.2.5
  catanh@GLIBC_2.2.5
  catanhl@GLIBC_2.2.5
  npy_catanh
  npy_catanhf
  npy_catanhl
  

• for with_meson == "no":

  npy_catanh
  npy_catanhf
  npy_catanhl
  

For further details see
- conda-forge/numba-feedstock#128 (comment)
- conda-forge/numpy-feedstock#304 (comment)

Reproduce the code example:

import numpy as np
assert np.signbit(np.arctanh(-1j).real)

Error message:

No response

Runtime information:

[{'numpy_version': '1.26.0',
  'python': '3.11.6 | packaged by conda-forge | (main, Oct  3 2023, 10:40:35) '
            '[GCC 12.3.0]',
  'uname': uname_result(system='Linux', node='20df351fb29c', release='6.1.55-1-MANJARO', version='#1 SMP PREEMPT_DYNAMIC Sat Sep 23 12:13:56 UTC 2023', machine='x86_64')},
 {'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
                      'found': ['SSSE3',
                                'SSE41',
                                'POPCNT',
                                'SSE42',
                                'AVX',
                                'F16C',
                                'FMA3',
                                'AVX2'],
                      'not_found': ['AVX512F',
                                    'AVX512CD',
                                    'AVX512_KNL',
                                    'AVX512_KNM',
                                    'AVX512_SKX',
                                    'AVX512_CLX',
                                    'AVX512_CNL',
                                    'AVX512_ICL',
                                    'AVX512_SPR']}}]
None

Context for the issue:

The regression caused inconsistent behavior in numba's test suite:
- conda-forge/numba-feedstock#128 (comment)

I did not investigate which other functions and/or use cases are affected.
Builds with/without using meson can be retrieved for further inspected at
- https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=819015&view=artifacts&pathAsName=false&type=publishedArtifacts

[mbargull]

BTW: While looking for possibly existing issue in https://github.com/numpy/numpy/issues?q=glibc+meson I noticed talk about deprecating npymath's implementation of these function and planning for raising glibc minimum version.

Is there some kind of documentation or tracking issue about which base system requirements NumPy (e.g., glibc, macOS deployment target, Windows *CRT) is targeting and planning to target in the future?
N.B.: On conda-forge we'll only start to link to glibc=2.17/CentOS 7 by default mid next year.
When we'll move to a newer target is not yet set; one can assume not after end of June 2028 -- but how much earlier is yet to be determined.
I'd be helpful to have a place in NumPy's docs/issues for us to refer to for planning.

[mattip]

We follow the EOL dates as collated in this page for deciding what manylinux wheels to build, but that is not relevant for conda. There is support for non-meson glibc blocklisted routines (for glibc<2.18) should be tracked here

numpy/numpy/_core/src/common/npy_config.h

Line 141 in 7ff7ec7

#if !__GLIBC_PREREQ(2, 18)

.

I see catanh in that list. Perhaps there is something off with the way we are using meson?

[mbargull]

There is support for non-meson glibc blocklisted routines (for glibc<2.18) should be tracked here

numpy/numpy/_core/src/common/npy_config.h

Line 141 in 7ff7ec7

#if !__GLIBC_PREREQ(2, 18)

.

I see catanh in that list. Perhaps there is something off with the way we are using meson?

In a local build I actually tried to eliminated that as a source of error via

-#if defined(HAVE_FEATURES_H)
+#if 1
 #include <features.h>
 
-#if defined(__GLIBC__)
-#if !__GLIBC_PREREQ(2, 18)
+#if 1
+#if 1

but it did not make any difference. [EDIT: Maybe I only replaced the __GLIBC* ones then? The culprit was actually that HAVE_FEATURES_H and __GLIBC* were not defined.]
It has been confusing for me why that doesn't trigger.
But since I'm not really familiar with NumPy's build setup, this was were I stopped.

Apart from the obvious readelf --dyn-syms check above, other differences in the builds from https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=819015&view=artifacts&pathAsName=false&type=publishedArtifacts didn't jump out for me too. Maybe you can make more sense of those?

[seberg]

Tried to figure things out a bit, but don't really see what might be wrong. One thing that does look wrong is that the meson defines set the value to 0 or 1 but the code uses #ifndef. However, that seems unrelated to this observation.

[mbargull]

The #undefs were not done because HAVE_FEATURE_H was not properly set in the Meson build, i.e., __GLIBC__/__GLIBC_PREREQ were not defined.
gh-25092 fixes this and gh-25093 is a backport for 1.26.x.