Actually my device is 6.0. Seems there's nothing interesting between API 23 and 24 on android-changes-for-ndk-developers.md :)

Anyway, _decimal should not depend on the whether the python binary references to libm.so or not. Instead, _decimal should explicitly have an explicit DT_NEEDED entry to libm.so if it uses symbols from libm.

> Strange that on other systems the compilers don't complain (usually they do).

I guess on most system python is built with --enable-shared, so _decimal.so has an entry to libpython3.7m.so, and the latter references libm.so. If a linker supports recursive search, it can find the symbol.

For future references, here's the partial output of logcat when I run python with `LD_DEBUG=3 python3.7m` and import _decimal:

02-07 19:43:25.697  10266    10266                 linker  D  DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in python3.7m (from global group)
02-07 19:43:25.697  10266    10266                 linker  I  SEARCH log10 in python3.7m@0x55634f3000 h=735a40(elf) 452
02-07 19:43:25.697  10266    10266                 linker  I  NOT FOUND log10 in python3.7m@0x55634f3000 735a40 452
02-07 19:43:25.698  10266    10266                 linker  D  DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in /system/vendor/lib64/libNimsWrap.so (from global group)
02-07 19:43:25.698  10266    10266                 linker  I  SEARCH log10 in /system/vendor/lib64/libNimsWrap.so@0x7f7c5fb000 (gnu)
02-07 19:43:25.698  10266    10266                 linker  I  NOT FOUND log10 in /system/vendor/lib64/libNimsWrap.so@0x7f7c5fb000
02-07 19:43:25.698  10266    10266                 linker  D  DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so (from local group)
02-07 19:43:25.698  10266    10266                 linker  I  SEARCH log10 in /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so@0x7f7c157000 h=735a40(elf) 49
02-07 19:43:25.698  10266    10266                 linker  I  NOT FOUND log10 in /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so@0x7f7c157000 735a40 49
02-07 19:43:25.698  10266    10266                 linker  D  DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in libdl.so (from local group)
02-07 19:43:25.698  10266    10266                 linker  I  SEARCH log10 in libdl.so@0x0 h=735a40(elf) 0
02-07 19:43:25.698  10266    10266                 linker  I  NOT FOUND log10 in libdl.so@0x0 735a40 0
02-07 19:43:25.698  10266    10266                 linker  D  DEBUG: /data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so: looking up log10 in /system/lib64/libc.so (from local group)
02-07 19:43:25.698  10266    10266                 linker  I  SEARCH log10 in /system/lib64/libc.so@0x7f7c4f6000 (gnu)
02-07 19:43:25.698  10266    10266                 linker  I  NOT FOUND log10 in /system/lib64/libc.so@0x7f7c4f6000
02-07 19:43:25.698  10266    10266                 linker  D  DEBUG: cannot locate symbol "log10" referenced by "/data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_decimal.cpython-37m.so"...

And BioniC's linker only checks HASH table of ELF: https://android.googlesource.com/platform/bionic/+/master/linker/linker_soinfo.cpp#277, so log10 is not found in python3.7m

> This is misleading

Maybe it is. I mean "I didn't write a patch for _decimal at issue21668 as _decimal didn't build then"

> Perhaps test_decimal should fail for CPython if _decimal can't be imported.

I create a simple script to ensure all installed dynamic modules can be imported: https://github.com/yan12125/python3-android/blob/master/devscripts/import_all.py. It may be worth to transform it into a proper unittest and put it into Lib/test/