Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: -C export-executable-symbols #2841
Add the ability to export symbols from executables, not just dylibs, via a new compiler flag: -C export-executable-symbols.
(Bonus: I've also implemented and used this flag as a proof-of-concept to make sure I am indeed solving my problems with this suggestion, but I'm happy to rewrite or discard that if another approach seems better.)
Specifying a .cargo/config file alongside/above Cargo.toml in the project tree works, but it'd be possible to extend Cargo.toml manifests as well - the most similar looking options all live under [profile.*]. Could be a new option:
[profile.dev] export-executable-symbols = true
On the other hand, this is a niche enough use case, that just leaving it as a custom rustc flag might be more than enough. For my own use cases, I'm likely to want to apply the setting to an entire workspace once and forget about it - instead of configuring it on a per-profile or per-package basis - so I'm likely to resort to an in-tree .cargo/config regardless.
Its sort of unfortunate that this RFC is written in a fashion where it sounds like it is saying "just do what dylibs do, but on executables", when at least currently, the semantics of dylibs are ... in flux at best.
(That is, to my knowledge, there is not much specification for dylibs themselves beyond "keep rustc working, and maybe try to keep compiler-plugins working for a little while longer." For some examples of the complications involved, see the discussion on rust-lang/rust#37530.)
So let me ask some basic questions, where I would like an answer more specific than "just do what dylibs do":
The behavior of which symbols to export should match what we do for
A crate wide attribute to toggle exporting symbols is a valid alternative and should go in the alternatives section. I am neutral on crate wide attribute vs rustc flag and would be happy with either.
I'm interested in explicitly annotated items:
The current behavior seems to be to export anything tagged
I don't, although I could see some proprietary devs not wanting to export the entire universe. They'd likely have similar concerns with dylibs, however.
A source attribute would probably work fine? My only possible concern would be ease of implementation - piping that information up to the linking stage - although I'd be happy to take a stab at it if that seems preferable.
Finer grained control over exports could be useful to dylibs as well, for those who want fine grained control. E.g. one might have middleware looking to link against a specific known