Hacker News new | ask | show | jobs
by 102030485868 3782 days ago
I'm not sure how likely that'll be. It's definitely possible, but I think there are going to be a few hurdles. The main one being, symbol versioning.

This is important if you export multiple symbols for a function, that is, have a program that depends on a specific implementation of a function. That could mean you depend on different versions of the same library ("functionname@@VERSION_1, functionname@@VERSION_2"), or completely different implementations of a function ("functionname@@IMPL_X_VER_1", "functionname@@IMPL_Y_VER_2").

Wait a second. That seems like a strange feature to want, right? Well. It's particularly useful for runtime library fun stuff. LD_PRELOAD in a library that magically changes the implementation of function. A cool example of this is of preeny[1], a collection of libraries to help with debugging.

Additionally, it's useful for replacing libraries that would depend on C implementations without having to recompile them, though some preloading magic at runtime may be required.

This is only the thing, for me at least, that's blocking for making Rust system libraries. Now, any sane person may say, "Cargo will take care of versions and stuff", and that's true. Sadly, that's not the case if you ever want to use those nice and safe Rust libraries from C though.

Though, I may be completely wrong about the state of symbol versioning in Rust. I simply ran 'nm -g libopenssl.so' on sfackler's rust-openssl project and failed to see any @@<version> in the output -- that is specifically being exported, and not re-exported, by libopenssl. There may be better libraries to use, but eh.

I could be completely wrong on this though. I've been mainly going off of what I read here[2], and here[3] (alternatively, for a more in-depth version, try here[4]).

TL;DR: symbol versioning may not be a thing.

Disclaimer: I've had to use symbol versioning pretty heavily, so it's important to me. I could also be completely wrong about Rust not having it.

[1]: https://github.com/zardus/preeny [2]: https://gcc.gnu.org/wiki/SymbolVersioning [3]: https://www.akkadia.org/drepper/symbol-versioning [4]: https://www.akkadia.org/drepper/dsohowto.pdf

1 comments

The default name mangling of Rust library symbols is already kinda versioned because it includes a hash of the library, so two different versions of a library can coexist at the same time.

As far explicitly using the symbol versioning scheme you mentioned, you can do it with an attribute today:

https://play.rust-lang.org/?gist=92be155702d53c6411b2&versio...

(Disclaimer: I haven't actually compiled this as a dynamic library and checked, but its what that attribute is for, and the names seem to be used verbatim in the ASM output)

Woah, I didn't know that is a thing. Thank you!

It seems as if symbol versioning in Rust is nicer than in C. I'll have to play around with that a little bit.

I'm hoping I never to have to deal with writing version scripts or inline assembly again -- or at least having to write less.

Note that I'm not really familiar enough with versioned symbols to know whether there is much more to it than just a specially formatted name.