I’m trying to embed rustc in an iOS app (roughly to produce a “learn rust” IDE-like environment for iPad). Assuming that the rust compiler is fully embedded in the app, and that I only compile to WASM and execute the result in an embedded WebKit view, it ought to pass muster in AppStore review - but I’ll cross that bridge when I get to it.
In the meantime, I’m running into issues that affect progress:
- The compiler crates are only built as dynamiclib, so can’t be built into a staticlib suitable for embedding.
- The compiler won’t produce dynamiclibs for any
I can trivially correct (1) by adding rlib targets to each compiler crate, as in https://github.com/rust-lang/rust/pull/55860. Alex doesn’t sound very positive on the topic of building these by default (and sadly cargo doesn’t provide target type overrides for dependencies).
There’s a possibility that I wouldn’t need to solve (1) if it weren’t for (2). I presume the
*-ios targets refuse to build dylibs because Apple traditionally didn’t support dynamic linking on iOS, but to the best of my knowledge they relaxed that restriction after iOS 8, and dylibs can be linked if packaged as a codesigned embedded framework. I haven’t had a chance to test whether this would actually pass App Store review, and the internet has mixed opinions on the topic.
Regardless, I’d like to understand why the compiler crates are built as dylibs in the first place. Is this a space optimisation because multiple tools include the same crates? A startup-time optimisation?
How much overhead are we talking about if I were to introduce the rlib targets in addition? The intermediates should all be shared between the dynamiclib and the rlib, no?