Chi Hsuan Yen added the comment: 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/ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29439> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
