Error compiling with extern crate "tflite"

I got the following error on macOS when compiling a SC with the extern crate “tflite” which accessed from local storage. When building only the crate the error does not happen. Any ideas what module could cause the error?

error: failed to run custom build command for `tflite v0.7.0 (/Enigma/extern_crates/tflite)`

Caused by:

process didn't exit successfully: `/Enigma/secret_contracts/simple_addition/target/release/build/tflite-9a7a854401392085/build-script-build` (exit code: 101)

--- stderr

/usr/local/opt/llvm/bin/../include/c++/v1/__config:1081:6: error: "No thread API"

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/signal.h:34:2: error: architecture not supported

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/machine/_mcontext.h:31:2: error: architecture not supported

fatal error: too many errors emitted, stopping now [-ferror-limit=]

/usr/local/opt/llvm/bin/../include/c++/v1/__config:1081:6: error: "No thread API", err: true

Hello @sepia! Thanks for bringing up the question and sorry for the late reply.
Secret contracts run inside a constrained WASM sandbox environment, and are compiled to that target. In general, only a limited subset of APIs are available inside this environment (for example, you do not have any notion of a filesystem, and instead we provide the custom secret storage system), but more specifically, threads are not a feature of the WASM runtime itself. If such functionality will be added to the runtime we use in the future, we will certainly consider updating it and adding support for it.

When using crate from crates.io ecosystem, please keep in mind that they are mostly written to target rust’s tier 1 targets, which WASM isn’t one of (we target wasm32-unknown-unknown, which is tier 2). This means that you’re only guaranteed that no_std crates will work flawlessly. each crate that uses the standard library, or attempts to invoke any additional bindings (such as your example) has a chance of encountering such issues. Some can be resolved on a case-by-case basis, but unfortunately some crates will inevitably hit one of the limitations of the secret-contract runtime, and will fail to compile, or run correctly.

2 Likes

thanks @reuven for the clarification, that makes sense.