The prebuilt iden3 archives are non-PIC, so they cannot be linked into a
downstream cdylib (e.g. the node's C bindings) — rust-lld fails with
"relocation R_X86_64_PC32 ... recompile with -fPIC". They are also built
against a newer glibc (undefined __isoc23_strtoll/ull on older runners).
For the static feature on glibc-Linux, build rapidsnark from source with
CMAKE_POSITION_INDEPENDENT_CODE=ON against the host toolchain instead. This
produces PIC archives that link into a shared library and, being built against
the host glibc, removes the __isoc23 dependency — so the previous compat shim
(isoc23_compat.c) is no longer needed and is removed.
All other targets (macOS, iOS, Android) keep using the prebuilt download path.
Verified in a glibc-2.35 container: the from-source archives link into a
-shared cdylib with rust-lld and carry no __isoc23 references.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The prebuilt iden3 rapidsnark archives are compiled on a glibc >= 2.38 host
(Ubuntu 24.04 / GCC 13), whose headers redirect strtoll/strtoull to the C23
interceptor symbols __isoc23_strtoll / __isoc23_strtoull. When the static
archives (static-rapidsnark feature) are linked on a host with an older glibc
(e.g. glibc 2.35), those symbols are undefined and linking fails:
rust-lld: error: undefined symbol: __isoc23_strtoull
Compile thin forwarders to the classic strtoll/strtoull symbols and link them
via whole-archive so the static path resolves regardless of the host glibc
version. Gated to the static feature on glibc-Linux; the shared library and
all other targets are unaffected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
