[nanvix] E: Phase 1B — build 5 Tier-1 math + memory modules as .so (with libm-unbundling)

[esaurez]

Summary

Phase 1B of the .a → .so migration. Promotes 5 Tier-1 "math + memory" stdlib extension modules from statically linked into python.elf to dlopen-loaded shared objects: math, cmath, _statistics, mmap, _contextvars.

This PR also drops libm.a from the per-module .so link commands — the canonical Linux-style pattern where each .so carries only its CPython glue and resolves sqrt / cbrt / etc. against python.elf's .dynsym at dlopen time. The previously-separate "drop libm.a from math .so" PR (#7) is folded into this one per esaurez's preference for consolidated review.

Modules moved to *shared*

Group	Modules
libm consumers	math, cmath, _statistics
libc-only	mmap, _contextvars

libm dlopen-resolution

Passes --with-libm= (empty) to CPython's configure so the math / cmath / _statistics .so link commands no longer include libm.a. Each .so ends up with sqrt / cbrt / etc. as undefined references resolved at dlopen time against python.elf's .dynsym. python.elf has them as GLOBAL DEFAULT because libm.a is in python.elf's --whole-archive LIBS plus the libposix visibility-merge contamination is fixed at the Nanvix level (nanvix#26).

This matches how Linux dlopen'd CPython math modules resolve libm — through the main executable's .dynsym (Linux uses libm.so.6 instead of the static link; the resolution mechanism is identical).

Note on the 11 newlib-internal __math_* helpers

__math_invalid, __math_oflow, __math_uflow, __math_divzero, etc. are GLOBAL HIDDEN at source in newlib/libm/common/math_config.h (ported from ARM optimized-routines, same as glibc and musl). They are deliberately library-private and do not appear in python.elf's .dynsym — and that is correct, not a bug. They are called only from inside libm's own internals (e.g. __ieee754_sqrt → __math_invalid), which live inside python.elf alongside the helpers themselves; the PC-relative call between them is resolved at static-link time and never touches .dynsym. dlopen'd modules don't need them — they call public names like sqrt, which dispatches to python.elf's sqrt, which internally calls __math_invalid if needed. This is identical to how Linux ships libm.so.6 with the same HIDDEN attribute on the same helpers; dlopen'd Python extensions on Linux never need to look them up either.

Size impact

Module / metric	Before (Phase 1A)	After (this PR)	Delta
math.so	(built-in)	381 KB (was 532 KB pre-drop-libm)	—
cmath.so	(built-in)	91 KB (was 180 KB pre-drop-libm)	—
_statistics.so	(built-in)	18 KB (was 28 KB pre-drop-libm)	—
mmap.so	(built-in)	54 KB	—
_contextvars.so	(built-in)	11 KB	—
python.elf	19.31 MB	19.18 MB	−130 KB

Test coverage

New phase1b_snippet in .nanvix/test.py imports each module, asserts non-builtin status, exercises one trivial API call (math.sqrt(4.0), cmath.sqrt(-1), etc.), and prints __file__. Phase 1A probe retained.

Validation

Tested on phase0-llfix toolchain overlay:

• All 5 new .so files produced and installed under lib-dynload/.
• nm python.elf no longer shows PyInit_<name> for any of the 5.
• readelf --dyn-syms python.elf shows sqrt / cbrt / fma as GLOBAL DEFAULT (the libposix-fix from nanvix#26 makes this work).
• math.sqrt(4.0) == 2.0 and cmath.sqrt(-1) == 1j round-trip via dlopen.
• Hello + Phase 1A probe + Phase 1B probe + lxml + HTTP smoke + full regrtest 160/160 PASS in standalone mode.

Prerequisites

Stacked on Phase 1A (esaurez/cpython#5). Requires esaurez/nanvix#26 merged AND the toolchain image rebuilt to carry the patched libposix.a. Without that fix, math.so dlopen would fail with ImportError: symbol not found on sqrt — exactly the failure mode that motivated nanvix#26.

Risk

Mechanical configuration change — 5 entries added to *shared* block of Setup.local, one-line change in Makefile.nanvix to drop libm from per-module .so LDFLAGS. All tests verify behavior is unchanged.