@cschramm Thank you very much for your detailed problem analysis and test report.
I plan to support three build strategies in the next release: 1. `no_std` 2. build-std in `xargo` (using `xargo build`) 3. build-std in `cargo` (using `cargo-std-aware)` In my current work in progress, most of the base crates builds are good using `build-std` build strategy, e.g. `mio,` `serde,` `rustls,` etc. But compatibility is still a tricky issue, e.g., the problem mentioned in your report, SGX unsupported instructions (`cpuid,` `syscall,` etc.). Compatibility issues that I often encounter in my testing. 1. `libc::syscall` 2. unsupported `libc` api (not implemented via ocall in `sgx_libc)` 3. `cpuid` instruction For incompatible third-party crates, it can be resolved by the following ways: 1. Provide a compatible API. 2. Manually port the third-party crates to adapt to SGX env, and then override the dependent crate on crate.io with `[patch]` in Cargo.toml. -- Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave-sgx-sdk/issues/311#issuecomment-1036006899 You are receiving this because you are subscribed to this thread. Message ID: <apache/incubator-teaclave-sgx-sdk/issues/311/[email protected]>
