Make cdylib only build when C API required #2685
Labels
Comments
seanmonstar
added
B-upstream
3 tasks
|
It's now possible in nightly to enable this at runtime: Since the C API is "experimental", perhaps we can require that nightly cargo be used already... |
|
@bagder how do you feel about using "nightly" cargo. If installing Rust with The background here is that currently hyper sets in its manifest to build both a Rust lib ( |
|
Whatever helps you go about this in a more convenient manner I will adapt to. Using nightly like this sounds totally doable in my end! |
seanmonstar
added
B-upstream
cschramm
added a commit
to yaxitech/incubator-teaclave-sgx-sdk
that referenced
this issue
Feb 3, 2022
Motivation: There are two basic strategies to use teaclave with existing Rust crates:
* Opt into no_std (+ alloc). This restricts the usable crates to those with no_std support and patched ones that work without it if adapted accordingly and that is actually a huge restriction. Also, it just does not reflect the situation as sgx_tstd is a proper std, just not 100 % complete compared to std and using a different naming.
* Port all dependencies to explicit sgx_tstd support, mostly adding things like "use sgx_tstd as std;". This means manual work for everyting and especially a lot of maintenance hassle.
Strategy 3: Use sgx_tstd as a drop-in replacement for std. This turned out to work decently. With the current state you can build (note that I'm not saying "run" 😅) the current kitx main with just an extra rustc flag and one small patch (see below).
Steps taken:
* Rename the sgx_tstd lib to just std.
* Build a sysroot with it and its dependencies.
* Improve std-compatibility as far as necessary.
Building the sysroot is done by the build_sysroot.sh script, meant to be run in the sgx_tstd directory and taking the desired target path as an optional argument (../../sysroot otherwise). It leverages cargo's -Z build-std feature to build the core and alloc crates. panic_unwind could be added there as well but is currently included by adding the one from the sgx_panic_unwind directory as a dependency (I have no idea what the difference might be as there is no dependency on std anyway).
Enabled features for improved compatibility:
* thread and backtrace - they should be uncritical, thread is linked by a lot of crates, backtrace only marginally but at least anyhow expects it to be available in nightlies.
* net - is considered untrusted but will probably be inevitable. We will need to audit and monitor which dependencies use its API and what they do with it.
* untrusted_time and untrusted_fs - similar to net but we might not actually need their API. We will want to disable them in the long run, probably by patching dependencies or providing stub implementations of the affected API. I will gather a list of usages in current kitx dependencies to find a strategy for this.
Patches for improved compatibility:
* Re-export ::core::arch as arch
* Re-export some of the sync::Sgx* structures under their std names.
* Re-export thread::SgxThread as thread::Thread.
* Implement thread::Builder::stack_size - a pointless noop just for API compatibility.
* Implement stubs for process::{ChildStdin, ChildStdout, ChildStderr}. These will fail if they are actually called.
* Implement process::abort with the actual implementation from std.
Caveats:
* Obviously the provided std is incomplete. Most notably it does not have std::process (apart from the patches mentioned above).
* The sysroot does not have a proc_macro crate. kitx builds fine without it (however, do not try to e.g. cargo build -p proc-macro2).
* An explicit target is required when building, even if it's the default. Without a target, e.g. the syn crate's build.rs fails to build due to the missing std::process::Command. I do not get why this does not happen when providing a target, to be honest.
* At least the sgx-sdk nix package only has a static version of libsgx_tstdc and others in $SGX_SDK/lib, so building cdylibs will fail.
For the kitx workspace the last point means that you need to patch out crate-type cdylib from hyper's Cargo.toml (there is active work going on to remove it in general: hyperium/hyper#2685) but that is the only change necessary. It is also not possible to build the C and JNI binding crates for the same reason.
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's some problems with compiling hyper as a
cdylib(rust-lang/rust#82151), and even without problems, it's extra compilation work if you don't need to build a C library. The goal is to make it so users can opt-in to building acdylib, instead of it being always on. To that end, we've pushed a bit in the tooling to allow this, and here's the steps that need to be done:cargo rustc --crate-type cdylib(Cargo--crate-typeCLI Argument rust-lang/rfcs#3180)cdylibfrom hyper'sCargo.tomlmanifest--crate-typeflag rust-lang/cargo#10083The text was updated successfully, but these errors were encountered: