Created attachment 882587 [details] buiild.log ../numpy-1.26.2/numpy/core/src/multiarray/experimental_public_dtype_api.c:389:1: error: type of ‘PyUFunc_AddLoopFromSpec’ does not match original declaration [-Werror=lto-type-mismatch] 389 | PyUFunc_AddLoopFromSpec(PyUFuncObject *ufunc, PyObject *info, int ignore_duplicate); | ^ ../numpy-1.26.2/numpy/core/src/umath/dispatching.c:154:1: note: type mismatch in parameter 3 154 | PyUFunc_AddLoopFromSpec(PyObject *ufunc, PyArrayMethod_Spec *spec) | ^ ../numpy-1.26.2/numpy/core/src/umath/dispatching.c:154:1: note: type ‘void’ should match type ‘int’ ../numpy-1.26.2/numpy/core/src/umath/dispatching.c:154:1: note: ‘PyUFunc_AddLoopFromSpec’ was previously declared here ../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.h:15:1: error: type of ‘arr_interp_complex’ does not match original declaration [-Werror=lto-type-mismatch] 15 | arr_interp_complex(PyObject *, PyObject *const *, Py_ssize_t, PyObject *, PyObject *); | ^ ../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:667:1: note: type mismatch in parameter 5 667 | arr_interp_complex(PyObject *NPY_UNUSED(self), PyObject *const *args, Py_ssize_t len_args, | ^ ../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:667:1: note: ‘arr_interp_complex’ was previously declared here ../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.h:13:1: error: type of ‘arr_interp’ does not match original declaration [-Werror=lto-type-mismatch] 13 | arr_interp(PyObject *, PyObject *const *, Py_ssize_t, PyObject *, PyObject *); | ^ ../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:497:1: note: type mismatch in parameter 5 497 | arr_interp(PyObject *NPY_UNUSED(self), PyObject *const *args, Py_ssize_t len_args, | ^ ../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:497:1: note: ‘arr_interp’ was previously declared here
Created attachment 882588 [details] environment
We may be able to workaround this on a nicer level like Eli did with scipy.
Created attachment 882589 [details] make.conf
same error at numpy-1.26.3
(In reply to Sam James from comment #2) > We may be able to workaround this on a nicer level like Eli did with scipy. i.e. https://github.com/scipy/scipy/pull/19857 rather than wholescale filter
ugh, this is kind of nasty -- it's clashing with an experimental API rework?
To clarify, the SciPy changes made sense to upstream because it affected some particularly old Fortran code that needs either serious modernization or to be replaced with brand new cython-based logic. And they'd rather the latter, I believe. What this means is that LTO failures are both "expected" and "we will never fix this, good luck", so it makes sense to disable it altogether there. I suspect they'd rather a proper fix for numpy, if it affects new code...
These warnings got indirectly reported at https://github.com/numpy/numpy/issues/25642.
I wonder if there's a way to disable building the experimental API.
reproducible with numpy-1.26.4
https://github.com/numpy/numpy/pull/26616#issuecomment-2149539167
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b005b8564d8f8fe41971bafdc9d2f88c009d720 commit 7b005b8564d8f8fe41971bafdc9d2f88c009d720 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-16 00:06:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-16 00:06:57 +0000 dev-python/numpy: filter LTO, add bug references Closes: https://bugs.gentoo.org/853901 Closes: https://bugs.gentoo.org/922457 Signed-off-by: Sam James <sam@gentoo.org> dev-python/numpy/numpy-1.26.4.ebuild | 3 +++ dev-python/numpy/numpy-2.0.0_rc2-r1.ebuild | 3 +++ 2 files changed, 6 insertions(+)