Cross-compiles a plugin's lang: :cpp_archive NIF — a set of C/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 (and :cflags* for .c sources), so a plugin author keeps control of its own ABI. One exception: Arm-only flags (-mbranch-protection=) in the Android lists are dropped on :android_x86_64, where clang rejects them, so one Android flag list can serve every ABI.

C and Objective-C sources

A .c or .m entry in :sources is compiled by the target's C driver (clang, not clang++) with :cflags / :cflags_android / :cflags_ios in place of the CXXFLAGS (forced -fPIC, the target ABI flags and the -I includes still apply). Mixed C/C++ libraries such as ggml need this: their .c files are not valid C++. An Objective-C NIF (.m) archived beside an Objective-C++ renderer (.mm) needs it too: clang++ compiles a .m as Objective-C, and a C++ flag such as -std=gnu++17 is then a hard error. Every other extension goes to clang++, which picks the language from the extension (.cpp/.cc C++, .mm Objective-C++).

Object files are named <basename>-<hash of the source path>.o, so two sources with the same basename in different directories (ggml's quants.c and arch/arm/quants.c) both land in the archive. Sources compile in parallel.