simplicity-sys: separate out linker symbols in C library by version name #297
Conversation
There are actually only two changes here:
* In vendor-simplicity.sh I added a couple `sed` lines to search-and-replace
simplicity_ symbols with rustsimplicity_X_y_ ones, then re-ran the script.
* In src/tests/ffi.rs I added a bunch of #[link_name] attributes to compensate.
One way to test this is to rename all the 0_4s to 0_3s e.g. with
find . -exec sed -i s/_0_4_/_0_3_/g {} \;
Then re-run vendor-simplicity.sh and see that your `git diff` has become empty.
|
cc @canndrew can you review this? Probably fine to just check that it seems half-sensible. I'm not sure it's worth your time to understand the vagaries of C/Rust FFI. |
|
Then if you're on a roll you can keep right on to #296. Feel free to ping me about how to use these vendoring scripts. |
|
Does this renaming resolve linker conflicts when running multiple versions of rust-simplicity in parallel? I am surprised, because we did a similar fix in the past. |
|
@uncomputable yes. And maybe you are thinking of:
|
|
For future reference, this set of fixes are there because otherwise when we update libsimplicity, our fuzztest (which attempts to compile both the local version of simplicity and the 0.3 release on crates.io) fails to build due to symbol conflicts. This failure manifests in CI and you can reproduce it locally (with some difficulty, since you need to rebase #296 on the commit before this one, or just obtain commit You can see these failures (for now) at https://github.com/BlockstreamResearch/rust-simplicity/actions/runs/16205734263/job/45755435923?pr=296 and also I have uploaded the logs here so they won't be deleted The specific failures are which suggests that we don't notice conflicts except when we actually change methods, and maybe we hadn't changed any methods (at least, none that the fuzzer was trying to use) until now. |
The process here was: * Manually replace c_X with c_v0_3_X everywhere (actually only in two files, wrapper.h and jets_ffi.rs) * Run update_jets.sh and make sure it changes all the 0_3s to 0_4s. Note that now both update_jets.sh and vendor-simplicity.sh update wrapper.h. This is fine since the change is idempotent. But we really should clean up and combine these two scripts one of these days.. The 0_3 test is easy to do during review, though if you are on NixOS then replace the cabal build/exec lines by first nix-building the `haskell` target in Simplicity and then directly calling result/bin/GenRustJets in there.
As before, I first manually added _0_3_ version numbers, modified the vendoring script, ran it, and made sure that the resulting diff added 0_4s and worked.
This field tells Cargo what library we're linking in, and helps it provide sane error messages (rather than linker spew) when somebody tries to compile multiple versions of the library that link the same thing. When we provide a links field we should also provide a build field. This is set to build.rs by default, but crate2nix seems to get confused when one is present but not the other.
apoelstra
force-pushed
the
2025-07/domainsep
branch
from
382e327 to
901127b
Compare
|
cc @canndrew can you give this a cursory review and an ack? The other one is not ready because upstream is generating code with broken paths, but this one is good to go. |
|
ACK 901127b |
First several commits (all the ones that don't update libsimplicity) from #296.