Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[do not merge] meson catanh sign issue #304

Closed

Conversation

mbargull
Copy link
Member

@mbargull mbargull commented Nov 7, 2023

Checklist

  • Used a personal fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

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'll open an issue upstream later and let this build here with downloadable artifacts for inspection/comparison.
[EDIT]: Upstream issue: numpy/numpy#25087

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
    

Signed-off-by: Marcel Bargull <marcel.bargull@udo.edu>
Signed-off-by: Marcel Bargull <marcel.bargull@udo.edu>
Signed-off-by: Marcel Bargull <marcel.bargull@udo.edu>
…nda-forge-pinning 2023.11.07.08.59.34

Signed-off-by: Marcel Bargull <marcel.bargull@udo.edu>
@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Signed-off-by: Marcel Bargull <marcel.bargull@udo.edu>
@mbargull
Copy link
Member Author

mbargull commented Nov 8, 2023

Upstream fix at numpy/numpy#25093 .

@mbargull mbargull closed this Nov 8, 2023
@h-vetinari
Copy link
Member

We can backport the patch if you want? Though I think a 1.26.2 is on the way reasonably soon, because of issues with #302

@mbargull
Copy link
Member Author

mbargull commented Nov 9, 2023

Though I think a 1.26.2 is on the way reasonably soon, because of issues with #302

Yep, saw that too.

We can backport the patch if you want?

No strong opinion from my side. (TBH, I just fixed, but did not assess the impact of the issue.)
If there is need, one can cherry-pick 2620333 for main and bump the build number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants