Build error in build_nistcurves_p256.sh #124

Activity

1. JC-000 commented on Aug 22, 2026

   

   JC-000

   on Aug 22, 2026

   Owner

   More actions

   Thanks for the report — reproduced, and the cause is a stale libs/nistcurves
   submodule checkout rather than anything in your build command.

   The fix for you

   git submodule update --init --recursive
   

   then re-run make BACKEND=uci. If it still fails, git submodule status will
   show a + in front of the libs/nistcurves line, which means the checked-out
   commit differs from the one this repo pins; git submodule update --force --init --recursive will overwrite it.

   You should end up at:

    58f4cf53b28eb35c4872c93b9b6d799d031ff892 libs/nistcurves (v0.11.2)
   

   Why that error, specifically

   The member name in your output is the tell. nistcurves-p256-verify.a at the
   pinned v0.11.2 contains zp_config_p256verify.o — upstream gave each archive
   its own per-variant ZP object in v0.9.0. A bare zp_config.o, which is what
   your run found, only exists in that archive at v0.5.0 – v0.8.0. None of
   those releases supports the CONTRACT_ZP_DEFINES make variable at all (it
   landed upstream in v0.10.0), so the -D nistcurves_zp_ptr2=0x3d we pass is
   silently discarded, the symbol is never defined, and the post-check reports it
   absent.

   So your libs/nistcurves is somewhere in v0.5.0–v0.8.0 while your c64-https
   tree is at or near master.

   Reproduced by taking a genuinely fresh clone of master, then moving only the
   submodule checkout and re-running the wrapper:

   libs/nistcurves checkout	result
   v0.6.0 / v0.8.0	ERROR: zp_config.o exports nistcurves_zp_ptr2 = <absent> — your line, character for character
   v0.9.1	ERROR: zp_config_p256verify.o exports nistcurves_zp_ptr2 = <absent>
   v0.10.1 / v0.11.2	passes

   For the record, master itself is fine: a fresh git clone +
   git submodule update --init libs/nistcurves libs/x25519 + make BACKEND=uci
   links build/c64-https.prg here at 9114ff7. And every commit in this repo's
   history that uses CONTRACT_ZP_DEFINES already pins v0.11.2, so there is no
   commit you could have landed on where the script and the submodule disagree.

   What we're fixing on our side

   The message blames CONTRACT_ZP_DEFINES — a knob you never touched — when the
   real cause is a submodule four-plus releases behind the gitlink. That is a bad
   error and we're fixing it:

   • tools/integration/build_nistcurves_p256.sh gets a preflight that checks the
     submodule's working checkout before invoking make, and fails with the
     git submodule update remedy named directly.
   • tools/check_upstream_pins.py reads the gitlink via git ls-tree by design
     (so it works on a submodule that was never --init'd), which means it would
     have told you "v0.11.2, no drift" while your working tree said otherwise. It
     gets a mode that compares the two.

   Leaving this open until that lands.
2. JC-000

   added a commit that references this issue on Aug 22, 2026

   Merge pull request #125 from JC-000/fix/stale-submodule-preflight

   ...

   580b9c2
3. JC-000

   closed this as completedin #125on Aug 22, 2026