Building rapidsnark from source in build.rs required cmake/nasm/gmp on every
runner, which the self-hosted CI hosts lack. Instead, host pre-built -fPIC
static archives as a fork GitHub release and download them like before.
- build.rs: reverted to the download-based approach (the PIC archives are built
on glibc 2.35 so they carry no __isoc23 references; no compat shim needed).
- download_rapidsnark.sh: Linux x86_64/arm64 now download the -fPIC rebuilds
from this fork's `rapidsnark-pic-*` release; macOS/iOS/Android keep using the
upstream iden3 archives (which work fine).
- Add .github/workflows/build-pic-archives.yml: builds the -fPIC archives
(rapidsnark + GMP) inside a glibc-2.35 container and publishes/updates the
release. Trigger by pushing a `rapidsnark-pic-*` tag or via workflow_dispatch.
Verified locally (glibc-2.35 container): the produced archives link into a
-shared cdylib with rust-lld.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
