from build.log: ``` FAILED: scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so aarch64-unknown-linux-gnueabi-g++ -o scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so.p/meson-generated__ufuncs.c.o scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so.p/_cosine.c.o scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so.p/xsf_wrappers.cpp.o scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so.p/sf_error.cc.o scipy/special/_ufuncs.cpython-312-x86_64-linux-gnu.so.p/dd_real_wrappers.cpp.o -Wl,--as-needed -Wl,--allow-shlib-undefined -shared -fPIC -O2 -pipe -fomit-frame-pointer -Wl,-O1 -Wl,--as-needed '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/scipy-1.15.2/work/scipy-1.15.2-python3_12/scipy/special -Wl,--start-group scipy/special/libcdflib.a scipy/libdummy_g77_abi_wrappers.a scipy/special/libsf_error_state.so -Wl,--version-script=/usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/scipy-1.15.2/work/scipy-1.15.2/scipy/_build_utils/link-version-pyinit.map /usr/aarch64-unknown-linux-gnueabi/usr/lib64/liblapack.so /usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a /usr/aarch64-unknown-linux-gnueabi/usr/lib64/libblas.so -Wl,--end-group /usr/libexec/gcc/aarch64-unknown-linux-gnueabi/ld: /usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a(meson-generated_npy_math_complex.c.o): Relocations in generic ELF (EM: 62) ... ... ... /usr/libexec/gcc/aarch64-unknown-linux-gnueabi/ld: /usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a(meson-generated_npy_math_complex.c.o): Relocations in generic ELF (EM: 62) /usr/libexec/gcc/aarch64-unknown-linux-gnueabi/ld: /usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status ```
Created attachment 919645 [details] build.log in `xz -9`
Created attachment 919646 [details] PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ emerge --info
Created attachment 919647 [details] emerge --info
The issue is the `/usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a` part, but I would encourage you to try find a simpler failure first. It's not impossible it's caused by the meson.eclass change you've made locally for bug 751325 (you can't even get to this point without that, right?) Can you also include meson-log.txt?
Created attachment 919648 [details] meson-logs.txt (In reply to Sam James from comment #4) > The issue is the > `/usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a` > part, but I would encourage you to try find a simpler failure first. > > It's not impossible it's caused by the meson.eclass change you've made > locally for bug 751325 (you can't even get to this point without that, > right?) I guess, no, but I didn't check. > > Can you also include meson-log.txt?
(In reply to Sam James from comment #4) > The issue is the > `/usr/lib/python3.12/site-packages/numpy/_core/include/../lib/libnpymath.a` > part, but I would encourage you to try find a simpler failure first. > > It's not impossible it's caused by the meson.eclass change you've made > locally for bug 751325 (you can't even get to this point without that, > right?) > the `meson.eclass` patch doesn't seem to impact, same issue without the patch. The patched helped at configuring numpy, but doesn't have any effect for scipy.
OK, that's something at least :)
``` ----------- Called: `/usr/bin/aarch64-unknown-linux-gnueabi-pkg-config --libs xsimd` -> 0 Run-time dependency xsimd found: YES 13.1.0 Run-time dependency threads found: YES Determining dependency 'numpy' with pkg-config executable '/usr/bin/aarch64-unknown-linux-gnueabi-pkg-config' env[PKG_TMPDIR]: /usr/aarch64-unknown-linux-gnueabi/tmp/portage/._unmerge_ env[PKG_LOGDIR]: /usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/scipy-1.15.2/temp/logging env[PKG_CONFIG_PATH]: /usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/scipy-1.15.2/temp/python3.12/pkgconfig:/usr/share/pkgconfig env[PKG_CONFIG_SYSROOT_DIR]: /usr/aarch64-unknown-linux-gnueabi env[PKG_CONFIG_LIBDIR]: /usr/lib64/pkgconfig env[PKG_CONFIG]: /usr/bin/aarch64-unknown-linux-gnueabi-pkg-config ----------- Called: `/usr/bin/aarch64-unknown-linux-gnueabi-pkg-config --modversion numpy` -> 1 stderr: Package numpy was not found in the pkg-config search path. Perhaps you should add the directory containing `numpy.pc' to the PKG_CONFIG_PATH environment variable Package 'numpy' not found ----------- numpy-config binary missing from cross or native file, or env var undefined. Default target is not allowed for cross use numpy-config found: NO Run-time dependency numpy found: NO (tried pkgconfig and config-tool) Running command: /usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/scipy-1.15.2/temp/python3.12/bin/python3 -c 'import os os.chdir(os.path.join("..", "tools")) import numpy as np try: incdir = os.path.relpath(np.get_include()) except Exception: incdir = np.get_include() print(incdir) ' --- stdout --- ../../../../../../../../lib/python3.12/site-packages/numpy/_core/include --- stderr --- Running command: /usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/scipy-1.15.2/temp/python3.12/bin/python3 -c 'import os; os.chdir(".."); import numpy; print(numpy.get_include())' --- stdout --- /usr/lib/python3.12/site-packages/numpy/_core/include --- stderr --- ``` scipy DEPENDs on numpy. How did you end up with it not installed? Are you running `ebuild` instead of `emerge`?
(In reply to Sam James from comment #8) > scipy DEPENDs on numpy. How did you end up with it not installed? Are you > running `ebuild` instead of `emerge`? what the hell? I used `aarch64-unknown-linux-gnueabi-emerge -avt -j1 -l24 dev-cpp/benchmark ` and it has scipy as dep, which has numpy as dep. Numpy is installed, I can confirm it... wait.
it installed numpy to main system?
crossdev's numpy: (2.2.3) │ ~ PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ wgetpaste -s pgz -c ' equery f numpy' Your paste can be seen here: https://paste.gentoo.zip/Gmo3ASiW main system's numpy ( 2.2.2 ) wgetpaste -s pgz -c ' equery f numpy' Your paste can be seen here: https://paste.gentoo.zip/3K4tWChX
(In reply to Arniii from comment #11) > crossdev's numpy: (2.2.3) > │ ~ PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ wgetpaste > -s pgz -c ' equery f numpy' > Your paste can be seen here: https://paste.gentoo.zip/Gmo3ASiW > > main system's numpy ( 2.2.2 ) > wgetpaste -s pgz -c ' equery f numpy' > Your paste can be seen here: https://paste.gentoo.zip/3K4tWChX do I understand correctly that numpy on main system is now broken?
Created attachment 919649 [details] PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ wgetpaste -s pgz -c ' equery f numpy'
Created attachment 919650 [details] wgetpaste -s pgz -c ' equery f numpy'
(In reply to Arniii from comment #10) > it installed numpy to main system? if that's so, is numpy installation for cross compilation is broken too?
I don't know what's happened yet, sorry. I suggest debugging it with a clean head tomorrow. At a glance, the deps in scipy/numpy/pythran all look correct (they use DEPEND/RDEPEND correctly, they don't e.g. only have numpy in BDEPEND or something).
(In reply to Arniii from comment #13) > Created attachment 919649 [details] > PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ wgetpaste -s pgz -c ' > equery f numpy' I'm not sure equery even respects PORTAGE_CONFIGROOT. It may respect ROOT.
(In reply to Sam James from comment #17) > (In reply to Arniii from comment #13) > > Created attachment 919649 [details] > > PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ wgetpaste -s pgz -c ' > > equery f numpy' > > I'm not sure equery even respects PORTAGE_CONFIGROOT. It may respect ROOT. it seems to have different results for this and for `equery l numpy` (get list of installed numpy with version), so I guess it respects it.
(In reply to Sam James from comment #16) > I don't know what's happened yet, sorry. I suggest debugging it with a clean > head tomorrow. At a glance, the deps in scipy/numpy/pythran all look correct > (they use DEPEND/RDEPEND correctly, they don't e.g. only have numpy in > BDEPEND or something). agree.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=266047631ed9f1288226a999e075c48bd1beab4f commit 266047631ed9f1288226a999e075c48bd1beab4f Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-21 23:43:44 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-21 23:43:44 +0000 dev-python/scipy: add dev-python/pythran to DEPEND as well as BDEPEND It turns out that we need dev-python/pythran in both BDEPEND (for /usr/bin/pythran) *and* DEPEND for pythran-generated code to be compiled as it uses headers from pythran. Bug: https://bugs.gentoo.org/922782 Bug: https://bugs.gentoo.org/950050 Closes: https://bugs.gentoo.org/950049 Signed-off-by: Sam James <sam@gentoo.org> dev-python/scipy/scipy-1.14.1.ebuild | 10 +++++++++- dev-python/scipy/scipy-1.15.0.ebuild | 8 ++++++++ dev-python/scipy/scipy-1.15.1.ebuild | 8 ++++++++ dev-python/scipy/scipy-1.15.2.ebuild | 8 ++++++++ 4 files changed, 33 insertions(+), 1 deletion(-)
The fix for bug 922782 may or may not change this, not sure (not impossible that something got confused by pythran missing). Can you give fresh logs if it still fails?
I've `aarch64-unknown-linux-gnueabi-emerge -avt --depclean numpy xsimd` and `aarch64-unknown-linux-gnueabi-emerge -avt dev-cpp/benchmark` and scipy still fails. It doesn't seem to solve the problem.
Can you give fresh build.log and meson-log.txt? Thanks.
(In reply to Sam James from comment #21) > Can you give fresh logs if it still fails? They are literally looks the same, but one moment
Created attachment 919762 [details] new meson-log.txt
Created attachment 919764 [details] new build.log in `xz -9`
(In reply to Arniii from comment #15) > (In reply to Arniii from comment #10) > > it installed numpy to main system? > > if that's so, is numpy installation for cross compilation is broken too? Also I figured that neither numpy seems to overwritten by another numpy because values in ` PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnueabi/ wgetpaste -s pgz -c ' equery f numpy' ` seems to be adjusted to new root. So, every value in this should be prefixed with "/usr/aarch64-unknown-linux-gnueabi/"
it seems that neither `pkg-config --list-all` nor `aarch64-unknown-linux-gnueabi-pkg-config --list-all` has `numpy` in it, though it exists at : `/usr/aarch64-unknown-linux-gnueabi/usr/lib/python3.12/site-packages/numpy/_core/lib/pkgconfig/numpy.pc` /usr/lib/python3.10/site-packages/numpy/_core/lib/pkgconfig/numpy.pc /usr/lib/python3.11/site-packages/numpy/_core/lib/pkgconfig/numpy.pc /usr/lib/python3.12/site-packages/numpy/_core/lib/pkgconfig/numpy.pc
I'm not sure how pkg-config is supposed to find that given it's buried in there, but I'm not sure how this is supposed to work for Python packages with multiple impls installed?
Considering that I have one numpy.pc file for cross environment, I have tried to make scipy find it. 1. Fix `
(In reply to Arniii from comment #30) > Considering that I have one numpy.pc file for cross environment, I have > tried to make scipy find it. > > 1. Fix ` sorry, I started, then saw your response in IRC, and somehow this saved. please, mark this text as not important or spam or whatever
Created attachment 919792 [details, diff] patch if using pkg-config hack so... I understood why this happens and created a patch for pkg-config case. So, let's just read scipy's sources: ./scipy/meson.build : ``` # Uses the `numpy-config` executable (or a user's numpy.pc pkg-config file). # Will work for numpy>=2.0, hence not required (it'll be a while until 2.0 is # our minimum supported version). Using this now to be able to detect the # version easily for >=2.0. _numpy_dep = dependency('numpy', required: false) f2py_freethreading_arg = [] if _numpy_dep.found() if _numpy_dep.version().version_compare('>=2.1.0') f2py_freethreading_arg = ['--free-threading'] endif endif # NumPy include directory - needed in all submodules # The chdir is needed because within numpy there's an `import signal` # statement, and we don't want that to pick up scipy's signal module rather # than the stdlib module. The try-except is needed because when things are # split across drives on Windows, there is no relative path and an exception # gets raised. There may be other such cases, so add a catch-all and switch to # an absolute path. Relative paths are needed when for example a virtualenv is # placed inside the source tree; Meson rejects absolute paths to places inside # the source tree. # For cross-compilation it is often not possible to run the Python interpreter # in order to retrieve numpy's include directory. It can be specified in the # cross file instead: # [properties] # numpy-include-dir = /abspath/to/host-pythons/site-packages/numpy/core/include # # This uses the path as is, and avoids running the interpreter. incdir_numpy = meson.get_external_property('numpy-include-dir', 'not-given') if incdir_numpy == 'not-given' incdir_numpy = run_command(py3, [ '-c', '''import os os.chdir(os.path.join("..", "tools")) import numpy as np try: incdir = os.path.relpath(np.get_include()) except Exception: incdir = np.get_include() print(incdir) ''' ], check: true ).stdout().strip() # We do need an absolute path to feed to `cc.find_library` below _incdir_numpy_abs = run_command(py3, ['-c', 'import os; os.chdir(".."); import numpy; print(numpy.get_include())'], check: true ).stdout().strip() else _incdir_numpy_abs = incdir_numpy endif inc_np = include_directories(incdir_numpy) # Don't use the deprecated NumPy C API. Define this to a fixed version instead of # NPY_API_VERSION in order not to break compilation for released SciPy versions # when NumPy introduces a new deprecation. numpy_nodepr_api = ['-DNPY_NO_DEPRECATED_API=NPY_1_9_API_VERSION'] np_dep = declare_dependency(include_directories: inc_np, compile_args: numpy_nodepr_api) incdir_f2py = incdir_numpy / '..' / '..' / 'f2py' / 'src' inc_f2py = include_directories(incdir_f2py) fortranobject_c = incdir_f2py / 'fortranobject.c' npymath_path = _incdir_numpy_abs / '..' / 'lib' npymath_lib = cc.find_library('npymath', dirs: npymath_path) ``` A lot of code , isn't it? So, let's dive in: 1. pkg-config used once and for ~~nothing~~. 2. To find the `npymath` lib it uses path to includes of numpy. 3. it gets includes to numpy in any of two ways: a. Get it from meson's cross file in ``` [properties] numpy-include-dir = ... ``` b. Get it via **CALLING** python3 and `import numpy` in it. The b. is happenning and thus making chaos, since python3 in this case uses main system's python3, not cross python3 via a qemu-wrapper. So, my next patch to scipy works if do hack from https://bugs.gentoo.org/show_bug.cgi?id=950205 with cross-pkg-config script .
(In reply to Arniii from comment #32) > Created attachment 919792 [details, diff] [details, diff] > patch if using pkg-config hack I can happily confirm, that it works and I finally could compile both scipy and dev-cpp/benchmark.
