@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/1036006...@github.com>

Reply via email to