[build] E: Build libxslt.so and libexslt.so

[esaurez]

Summary

Produce position-independent libxslt.so and libexslt.so alongside the existing static .a archives, wired as a real DT_NEEDED chain on top of esaurez/libxml2#1's libxml2.so:

libxslt.so   -> NEEDED libxml2.so
libexslt.so  -> NEEDED libxslt.so, NEEDED libxml2.so

Only each .so's own .a is embedded via --whole-archive; the lower layers (libxml2, libz) are not bundled. The Nanvix dynamic loader pulls them in transitively at dlopen time via esaurez/nanvix#27.

Size impact (vs the discarded self-contained prototype)

Artifact	Self-contained	DT_NEEDED chain
libxslt.so	1.8 MB	296 KB
libexslt.so	1.9 MB	92 KB

~3.3 MB reclaimed in libxslt alone; the chain also eliminates the 6 MB of libxml2 duplication across the full stack (libxml2 → libxslt → libexslt → liblxml_etree).

Implementation

Change	Detail
--with-pic, -fPIC in CFLAGS	Same .o files reusable for .a and .so
Keep --disable-shared	libtool has no rules for i686-nanvix; the .so files are linked manually
New $(SHAREDLIB_XSLT) / $(SHAREDLIB_EXSLT) targets	gcc -shared -fPIC -nostdlib -Wl,--whole-archive <own>.a -Wl,--no-whole-archive -lxml2 [-lxslt], setting DT_SONAME=libxslt.so / DT_SONAME=libexslt.so
make test extended	Verifies presence, DT_SONAME, and that the public API entry points appear in .dynsym
.nanvix/z.py _BUILD_OUTPUTS and release()	Ship both static and shared variants

Validation

$ readelf -d libxslt/.libs/libxslt.so
 0x00000001 (NEEDED)  Shared library: [libxml2.so]
 0x0000000e (SONAME)  Library soname: [libxslt.so]

$ readelf -d libexslt/.libs/libexslt.so
 0x00000001 (NEEDED)  Shared library: [libxslt.so]
 0x00000001 (NEEDED)  Shared library: [libxml2.so]
 0x0000000e (SONAME)  Library soname: [libexslt.so]

The DT_NEEDED chain is correctly emitted; end-to-end resolution at runtime is validated downstream in esaurez/lxml#1 and the follow-up CPython integration.

Sequenced rollout

This PR's CI build needs libxml2.so present in the buildroot to emit the DT_NEEDED libxml2.so entry. That requires:

1. Merge esaurez/libxml2#1.
2. Cut a new esaurez/libxml2 release (the buildroot is populated from release tarballs).
3. Bump this repo's nanvix.toml pin to that release.
4. Then merge this PR.

Until step 3, CI satisfies -lxml2 against the existing libxml2.a in the upstream release tarball, which produces a libxslt.so without a DT_NEEDED libxml2.so entry — the build succeeds, just doesn't yet realize the chain benefit. The end-state expects libxml2.so to be present.

Runtime dependencies

• esaurez/nanvix#27 — .init_array invocation and DT_NEEDED chain walking in the user-space loader.
• esaurez/nanvix#28 — diamond DT_NEEDED handling. libexslt.so depends on both libxslt.so and libxml2.so, which itself forms a diamond once consumers (e.g. liblxml_etree.so) layer on top.
• esaurez/libxml2#1 — libxml2.so ships in its release.

Companion PRs

• esaurez/libxml2#1 — produces libxml2.so.
• esaurez/lxml#1 — consumes the chain to produce liblxml_etree.so for CPython.

Consumer

• esaurez/cpython#11 — Phase 4 of the CPython .a → .so migration consumes this chain at runtime via dlopen of liblxml_etree.so.

[esaurez]

Superseded by upstream PR nanvix#75, which carries the same .so build addition -- rebased onto current upstream version branch, scope-trimmed (CI workflow downgrade, nanvix.toml version downgrade, .gitignore tweaks, .zutils-version downgrade, z.ps1/z.sh additions all dropped as unrelated env drift), and esaurez/* / python.elf / nanvix-todo references cleaned from commit message and PR body. Closing this fork PR; tracking continues upstream.