I’m working on an environment that only runs wasm32-unknown-unknown
and things have been going well for some time.
I’m not doing anything with JavaScript, and I’m not using wasm-pack
, wasm-bindgen
, or anything like that.
I recently tried to use a dependency that depends on ring
for public key verification. This brought up a few issues and questions.
ring
has some C dependencies (among other things) and I’ve learned about issues with linking C when targeting wasm32-unknown-unknown
due to differences in the ABI so I also tried a pure* Rust version, but these ABI concerns are perhaps less relevant to my issue/question.
The Problem
It appears that ring
’s use of extern "C"
for calling C functions is clashing with the expected use of extern "C"
when targeting Wasm, which results in the Wasm module expecting something to be provided by the environment that is already part of the binary.
I’m hoping I can somehow address without major changes.
Information and observations below. Thanks in advance for any advice and suggestions.
ring 0.16.20
Everything builds successfully but my environment complains that Module imports function 'LIMBS_are_zero' from 'env' that is not exported by the runtime.
LIMBS_are_zero
originates here:
and as far as I can tell, the relevant C files are included in the build:
I noticed that the example in the docs on extern includes #[link(name = "my_c_library")]
.
That seems relevant for the version with C dependencies but not the version below.
ring-xous
Out of curiousity I tried replacing ring
with a modified version of ring-xous
, since that provides a pure Rust implementation via c2rust.
I still have reservations about this approach because it exchanges concerns about ABI stability compatibility with concerns about security, but for now it eliminates the C dependencies.
The same declarations are still there:
and the implementations are provided like this:
However, I still get the same Module imports function 'LIMBS_are_zero' from 'env' that is not exported by the runtime.
error.
I’m assuming that I could fork this and provide/use the rust implementations more directly (without the use of extern "C"
) but is that necessary?