Dunno why we haven't seen this elsewhere, but when trying to build
locally for an ARM embedded target `secp256k1-sys` failed to
compile as it was missing `string.h`, just like WASM.
This patch adds a trivial fallback - if we fail to compile
initially we unconditionally retry with the wasm-sysroot, giving us
a valid `string.h`.
Currently we are defining the WASM integer size and alignments in the
`stdio.h` header file, this is wrong because this file is included in
the build by way of `build.rs` as well as by upstream `libsecp256k1`.
Move WASM integer definitions to a `C` source file and build the file
into the binary if target is WASM.
cc-rs builds C dependencies with reduced visibility to avoid
exporting the C symbols all the way out to any rust-built shared
libraries however we override it with SECP256K1_API. We should
avoid doing this, allowing LTO/DCE to do its work.
This feature was not useful for Cargo users, since Cargo does not give you
the kind of fine-grained control over C library linkage that you need. So
it was just unnecessarily confusing and would cause the build to break if
you enabled it accidentally, say, with --all-features.
This is configurable in upstream now.
Fixes#214.
So far, this just sets it to `4`. It's tempting to set it to `2` when `lowmemory` is enabled
but `lowmemory` is about RAM and not about binary size. This is better addressed by
a resolution of #193.
libsecp256k1 really only barely uses libc at all, and in practice,
things like memcpy/memcmp get optimized into something other than a
libc call. Thus, if we provide simple stub headers, things seem to
work with wasm-pack just fine.
Elichai Turkel
Matt Corallo
Tobin Harding
Andrew Poelstra
Riccardo Casatta
Kirill Fomichev
Tibo-lg
Tim Ruffing
Steven Roose