Cross-compiles a plugin's lang: :cpp_archive NIF — a set of C++ sources — into lib<module>.a for one target ABI, and verifies the NIF-init symbol is present. The archive is then static-linked into the app's single signed native binary (same slot as crypto.a / libnx_eigen.a).

This is the generic, manifest-driven generalization of MobDev.NxEigenNif: the sources, include dirs, CXXFLAGS, and expected symbol all come from the plugin's Merge.static_archives/2 spec rather than being hardcoded. It exists because the single-source :c/:zig plugin NIF path (compiled inline by build.zig) can't express a C++ build with external headers (Eigen/Fine), RTTI/exceptions, a per-arch hardening flag set, and an archive output.

Why static-link (same as every on-device NIF)

• Android. A separately-dlopen'd .so inherits RTLD_LOCAL, hiding the BEAM's enif_* symbols → on_load fails. Static-linking lets the BEAM resolve the init symbol via dlsym(RTLD_DEFAULT) on the app binary.
• iOS. The App Store forbids loading unsigned dylibs / dlopen; the NIF must already be in the signed binary.

What the builder forces vs. what the plugin controls

The builder forces only -fPIC (a static lib linked into a shared object must be position-independent) and the compile/output flags (-c -o). Everything else — C++ standard, optimization, visibility, exceptions, the -DSTATIC_ERLANG_NIF_LIBNAME=… that fixes the emitted init symbol, and any Android hardening — is the plugin's via :cxxflags / :cxxflags_android / :cxxflags_ios, so a plugin author keeps full control of its own ABI.