Hash part in symbol names

It's possible disable generating hash parts in symbol names, generated by compiler?
For example: core::panicking::panic is mangled as __ZN4core9panicking5panic17h5eaccc6082f5fcb8E
I understand that hashes are used for versioning, but I need to disable their generation.

On things you define you can add #[no_mangle] to give them global, unhashed names. On extern items (non-Rust) you can add #[link_name=] to specify exact symbol name to link with.

You can't control symbols of other things.

It's not a solution. I need disable only hash part, in example above, hash part is "h5eaccc6082f5fcb8". How I can do it?

You can't, unless you make your own version of the compiler that mangles symbols differently.

This is probably the point where we should ask why you need this, so we can help you with alternative solutions/workarounds.

Are you trying to link with some non-standard SDK? Are you crosscompiling to an unsupported architecture? Are you parsing the symbol names in a performance report? Comparing generated assembly of different compiler versions?
What are you trying to do?

You apparently have something, which is not rustc or the linker, that needs a rust-mangled-name-but-without-the-hash. What is this "something"?

1 Like

I am trying to write a library whose changes in code will not lead to recompilation of other dependent libraries

1 Like

Rust does not have a stable ABI. The hash includes all of the things that might affect ABI, like the compiler version. It also disambiguates for crate versions (e.g. if you have multiple rand semvers) and generic type parameters, neither of which are otherwise represented in the symbol name.


Rust could, theoretically, maybe get a stable ABI, several years in the future. But we are nowhere near to reaching that goal.

Rust-lang Issue #600 documents some of the horror stories other languages have to deal with because they have an ABI. we do not want to join them in these problems until the language is far more mature.

Is this a compile-time/caching thing? Or something else?

If it's an problem of interoperability with another language, providing a C ffi might be a solution.

If it is because you want to distribute binary while keeping your code secret, you could look at the solution often used in the C++ world: provide source under Non-disclosure agreement ("NDA").

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.