Elizafox's Ramblings

I'm back in Seattle but I got shit to do. This is gonna be a short post.

As per my last post, I was experimenting with doing mangled import from Rust.

I now realise how bad of an idea that is.

Metadata

Every dylib contains metadata that helps elucidate the types of functions, struct layout, MIR code of generics, etc.

Unfortunately, parsing said metadata seems to be a nightmare, and pretty much only the Rust compiler knows how to do it.

Allocators

Turns out Rust dylibs may or may not need an allocator, and that has to be set up if you load something.

Unloading

Unloading a Rust dylib that isn't expecting to be unloaded means you're likely to have a bad time, as things get dropped that aren't expecting to be dropped.

Too many symbols

Rust exports basically everything into a Rust dylib, it doesn't really try to hide things or pare them down. This is pretty awful practice. It pollutes the namespace.

Unstable ABI

The Rust ABI is unstable, and subject to change at any time. Just because names are mangled more or less consistently, doesn't mean that you can just willy-nilly import things. There is more to the ABI than that. Said metadata is part of it as well (the .rustc section of a dylib).

Sigh

I hope one day this becomes a possibility, because this would be a big win.

In the meantime, I recommend checking out the abi_stable family of crates, which can help you include rich Rust in your crates, instead of just exporting a C ABI and making a cdylib.

— Elizabeth Ashford (Elizafox) Fedi (elsewhere): @Elizafox@social.treehouse.systems Tip jar: PayPal || CashApp || LiberaPay