|
|
# Linking Rust with C in Tor
|
|
|
|
|
|
== Tickets
|
|
|
|
|
|
Parent ticket: #25386
|
|
|
|
|
|
* Linking C libraries into Rust doctests #27915
|
|
|
* Adding a passthrough from cargo test doctests to rustc
|
|
|
|
|
|
* Switching Rust to use Tor's allocator
|
|
|
|
|
|
== Linking Process
|
|
|
|
|
|
The testing story for C code that needs Rust code is very complicated. It gets even more complicated for C -> Rust -> C.
|
|
|
|
|
|
1. Our configure script fills in fields in a config.rust file, that will be later read by the build script.
|
|
|
2. We invoke cargo in unusual ways
|
|
|
3. We try to stick all of the cargo output in a tor-rust.a library
|
|
|
4. When we are testing, we have a build.rs script, we mention this script in the cargo.toml file, so that rust can call into C
|
|
|
5. The script reads the config.rust file and uses the variables in that list to configure the linker
|
|
|
6. The test-linking-hack feature in src/rust/protover/protover.rs defines an alternate version of a function that does not use a given C function. This resolves circular dependencies when linking C -> Rust -> C doctests. (Doctests don't use build.rs, don't set config(test), and don't set config(doctest).)
|
|
|
|
|
|
== Static vs Dynamic Linking
|
|
|
|
|
|
Rust's static linking takes all the .o files from the linked library and puts them in the Rust .a lib.
|
|
|
|
|
|
Rust's dynamic linking defers the link step, and passes -L to the linker.
|
|
|
|
|
|
Rust passed -nodefaultlibs to the compiler, so that all libs are explicitly included in the linker command-line. Nightly now has a -linker-default-libs argument that adds default libs. |
|
|
\ No newline at end of file |