Skip to content

Rust support tracker issue

Phase 1 (1.22 dev cycle):

  • Initial work was at !261 (closed)
  • Current work is at !915 (merged)
  • Implement fetch + dynamic fetch for bootstrap
  • Install Cargo-C during bootstrap as a build-tool (oops!)
    • Implement a 'Cargo' build type (in addition to a cargo-c build type)
  • Implement fetch + extract + cargo vendor for Cargo-C recipes
  • Test build + install of gst-plugins-rs
  • Hook up and test packaging
  • Test and implement macOS x86_64 support
  • Test and implement Windows support
    • Support multiple toolchains at once (gnu vs visualstudio, 32-bit vs 64-bit)
    • closedcaption plugin isn't built with a static library on msvc 64-bit
    • On msvc 32-bit, sometimes vendor succeeds and then cargo-c fails to find dumpbin (!?)
  • Test and implement cross-macos-universal support
    • Implement cross-compile support for macOS ARM and x86_64
  • iOS universal preliminary support
  • Android universal preliminary support
  • Enable rust variant on the CI for at least Fedora
  • Enable rust variant for whatever is possible quickly for now
    • Currently enabled for linux, macos, windows (msvc). Not enabled for any target that uses the mingw toolchain, or for UWP, iOS, Android.
  • Document rust variant in README

Phase 2 (1.24 dev cycle):

iOS and Android blockers for enabling Rust variant by default

  • Static plugins are disabled because they need to have unused sections removed. They are currently 200-500MB in size.
    • Each static plugin contains its own copy of std and the minimum size of a static library is currently around 20MB: https://github.com/rust-lang/rust/issues/111594
    • This is because they contain objects for all crate dependencies. Strip does nothing, because these objects export tens of thousands of Rust symbols, and the symbol table contains all these, which marks them as used.
    • Need to find (or write) a tool that can edit the symbol table to remove all except gst_*, and see if strip works then.
    • If strip still can't detect unused sections automatically, we'll have to manually find and specify which sections can be removed.
    • It's also possible that rustc doesn't write out functions into separate sections, which will mean that needs to be fixed first by passing -C llvm-args=-ffunction-sections to rustc, perhaps via RUSTFLAGS.
    • cargo-c is always building an rlib which prevents LTO for staticlibs (https://github.com/lu-zero/cargo-c/issues/322 https://github.com/rust-lang/cargo/issues/2301)
  • Statically linking two or more Rust plugins, or statically linking a Rust plugin into a Rust app errors out with Clang, complaining about duplicate symbols: https://github.com/rust-lang/rust/issues/44322#issuecomment-1310211971
    • Workaround is to literally binary-patch the static libs to redefine the symbols
    • [fix]
  • gst-plugins-rs ships plugin pkgconfig files in the wrong place, since cargo doesn't support custom dirs
  • Disable Apple bitcode support in Cerbero
  • cargo-c refuses to build cdylibs on iOS and Android: https://github.com/lu-zero/cargo-c/issues/278
    • iOS behaviour seems to be by design
    • Android behaviour needs debugging, it should not be happening
    • This issue is not important, because we only support static libs on these platforms anyway
    • Fixed in Rust 1.65: https://github.com/rust-lang/rust/pull/100636

Phase 3 (1.26 dev cycle):

Blockers to using the Rust rewrite of librsvg

  • Rust support must be enabled by default on all supported platforms
    • iOS [done]
    • Android [done]
    • MinGW (see above), or disable the svg plugin on mingw
    • Either implement UWP support for Cargo recipes, or drop UWP support from Cerbero, or use hacks to keep it zombified
  • Static libs must be re-enabled on macOS, Linux, MSVC (see above) [done]
  • Port librsvg from autotools+cargo to meson+cargo-c
  • Update librsvg recipe to use latest release (rewritten in Rust), needed for at least gstreamer!5489
    • DLL and import/static library naming is incorrect on MinGW. If we use the same hack as for plugins, we need to also fix the DLL name inside the import library.

Important issues for making Rust a first-class citizen in Cerbero

  • Toolchain is installed twice; once in fetch-bootstrap, then again in bootstrap
    • The fix is more generic, all extracted / installed toolchains should have a manifest file in the toolchain root dir that lists what toolchain is installed, so that we don't extract / install twice. This affects all toolchains.
  • Cargo recipes run cargo vendor twice: once in fetch to update Cargo.lock and fetch deps, then again in extract
  • Debug information
    • Add PDB installation support to cargo-c -> fixed in cargo-c 0.10.0
    • Ship *.dwp debuginfo files for Android and Linux that are created by the split-debuginfo option to rustc. See also: #350
      • Using that option actually causes rustc to crash right now ...
      • Need to test that these files are correctly picked up by gdb, and if not, what we can do to fix that
    • Ideally, we should have a third package (besides runtime and devel) that ships debug information and source code

MinGW blockers for enabling Rust variant

  • When building with mingw 32-bit, Cargo wants to use i686-w64-mingw-gcc as a linker, which our multilib toolchain doesn't provide -> fix in !1501 (merged)
  • When building with mingw, cargo-c generates incorrectly-named foo.dll cdylibs (hacked around in recipe)
  • With native mingw 32-bit, vendoring randomly fails sometimes, failing to find files that do exist (difficult to reproduce, ignoring for now)
  • Split or strip cdylib debuginfo (fix)
Edited by amyspark