Package: python3-scipy
Version: 1.14.0-1exp1
Severity: serious
Justification: debci
scipy 1.14 builds libsf_error_state.so for the special submodule, from
sf_error_state.c, sf_error_state.h
The meson build controls are
sf_error_state_lib = shared_library('sf_error_state',
['sf_error_state.c'],
include_directories: ['../_lib', '../_build_utils/src'],
c_args: scipy_export_dll_args,
install: true,
install_dir: py3.get_install_dir() / 'scipy/special',
)
so it's intended as a shared library.
dh_python3 (or maybe pybuild) finds it and converts
libsf_error_state.so to
libsf_error_state.cpython-312-x86_64-linux-gnu.so
Then at runtime (or during tests) we get an error when accessing special
e.g.
$ python3 -c "import scipy.special"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3/dist-packages/scipy/special/__init__.py", line 807, in
<module>
from . import _ufuncs
ImportError: libsf_error_state.so: cannot open shared object file: No such file
or directory
lintian also reports an error:
W: python3-scipy: shared-library-lacks-prerequisites
[usr/lib/python3/dist-packages/scipy/special/libsf_error_state.cpython-312-x86_64-linux-gnu.so]
N:
N: The listed shared library doesn't include information about the other
libraries against which it was linked.
N:
N: More specifically, "ldd foo.so" should report such other libraries. In
your case, it reports "statically linked".
N:
N: The fix is to specify the libraries. One way to do so is to add something
like "-lc" to the command-line options for "ld".
sf_error_state.c does not use python as such. As far as I can see
libsf_error_state.so is intended to be an actual shared library, not a
python extension. In that case it should not be renamed to
libsf_error_state.cpython-312-x86_64-linux-gnu.so
Indeed if I manually changed it back to libsf_error_state.so then
special works as normal. Not sure what the best fix is, since multilib
is involved together with sonames.
_ufuncs.cpython-312-x86_64-linux-gnu.so is a "normal" python extension
in special, objdump -p shows it has
NEEDED libsf_error_state.so
Perhaps libsf_error_state.so could be moved to /usr/lib/<arch_triplet>/.
Alternatively perhaps the soname could be changed to
libsf_error_state_<arch_triplet>.so, keeping it in the scipy/special dir.
Moving it to the standard lib path in /usr/lib/ might arguably be simpler
(not sure if it's easy to get meson to embed an arch-triplet in the
soname)
