This is a commonly-used package for spatial indexing.
Strangely enough, the tests are broken due to memory unsafety that I was unable
to reproduce under Debian. For instance, when run with Python 3.6 valgrind
reports,
==10453== Invalid read of size 4
==10453== at 0x4EF1DFA: _PyObject_Free (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4FE7D96: _PyFaulthandler_Fini (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F8438D: Py_FinalizeEx (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F9F398: Py_Main (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x400BDF: main (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/bin/python3.6)
==10453== Address 0x67b1020 is 352 bytes inside a block of size 640 free'd
==10453== at 0x4C2DD6B: free (in /nix/store/6z028lfnxyhh8dlngpm6zrkwqxmbglj4-valgrind-3.13.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10453== by 0x4EDDC4A: free_keys_object (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4EDEE63: dict_dealloc (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4EECF59: module_clear (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4FA062B: collect (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4FA13A0: _PyGC_CollectNoFail (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F79CED: PyImport_Cleanup (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F8436F: Py_FinalizeEx (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F9F398: Py_Main (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x400BDF: main (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/bin/python3.6)
==10453==
==10453== Conditional jump or move depends on uninitialised value(s)
==10453== at 0x4EF1E03: _PyObject_Free (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4EFEF2D: type_dealloc (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4EFD009: subtype_dealloc (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4FA063E: collect (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4FA13A0: _PyGC_CollectNoFail (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F79DF8: PyImport_Cleanup (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F8436F: Py_FinalizeEx (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x4F9F398: Py_Main (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/lib/libpython3.6m.so.1.0)
==10453== by 0x400BDF: main (in /nix/store/azw9ys2m2fpfzf730xjcxja890gpyp58-python3-3.6.4/bin/python3.6)
==10453==
...
https://hydra.nixos.org/build/70700906
I opened an upstream bug, but their bug system is e-mail based and I
haven't got a single reply which contains an web link :(
Since at least d7bddc27b2, we've had a
situation where one should depend on:
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables,
regardless of the host platform, at run time.
and that commit cleaned up this usage to reflect that. This PR flips the
switch so that:
- `binutils` is indeed unconditionally GNU Binutils
- `binutils-raw`, which previously served that role, is gone.
so that the correct usage will be enforced going forward and everything
is simple.
N.B. In a few cases `binutils-unwrapped` (which before and now was
unconditionally actual GNU binutils), rather than `binutils` was used to
replace old `binutils-raw` as it is friendly towards some cross
compilation usage by avoiding a reference to the next bootstrapping
change.
