Allow export of Rust symbols from a C shared object via a staticlib

[adetaylor]

clang offers the ability to mark a symbol as exported or non-exported from a dynamic shared object (DSO) using __attribute__((visibility ("default"))) and __attribute__ ((visibility ("hidden"))). This issue requests the same in Rust, though it may be a bit more complex in the Rust case.

Another way of looking at it is to cleave the dual purpose of #[no_mangle] where it both sets visibility and alters the exported name.

The rest of this issue explains why this would be useful.

I am working in a pre-existing complex C++ codebase. It produces multiple DSOs, let’s say:

• libbase.so
• libservices.so

We want to build Rust code into each of those DSOs. Internally, the C++ and Rust code is intermixed freely (for example, the C++ JSON APIs within libbase.so call into a serde-based parser, which calls back into C++ to instantiate objects, etc.) There is no possibility of splitting these DSOs into separate DSOs for Rust and C++ code.

We build Rust code into these DSOs in the approved way, which is to aggregate a bunch of Rust libraries (rlibs) into a separate Rust staticlib for each of the DSOs. (For example, libbase_rust_deps.a and libservices_rust_deps.a). The final C++ linker links exactly one of these staticlibs together with the C++ .a and .o in the final construction of the DSO. That should be fine, since the whole point of a staticlib Rust target is to contain the Rust code and all its dependencies.

libservices.so depends on libbase.so. In C++, libservices.so uses symbols exposed from libbase.so. For example, there may be a CPP::Log function used by C++ code within both libbase.so and libservices.so. That’ll be exported from libbase.so using an __attribute__((visibility ("default"))) annotation in the source code for CPP::Log.

So far so good.

But now we want to put a Rust wrapper around that CPP::Log function, to make, say, rs_log. Ideally, there would be just a single implementation of rs_log in libbase.so. We want to be able to call that Rust wrapper from within the Rust parts of libbase.so or libservices.so.

This seems to be impossible.

Our options are:

• Build a dylib using rustc, which exposes all public Rust APIs from the DSO. We can’t do that for the reasons cited above; we need to build a staticlib as the Rust code is just a small component of existing DSOs. Rustc can’t be in control of the final linking.
• Mark rs_log as #[no_mangle] which successfully exports it from libbase.so, but using a C ABI which prevents Rust discovering and using this symbol even if downstream crates are built using --extern rust_base=./libbase.so

(this latter case gives

error[E0463]: can't find crate for `rust_base`
  --> ./rust_static_libs/libservices_rust_deps/mod.rs:20:1
   |
20 | extern crate rust_base;
   | ^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

)

Solution?

It’s a problem that #[no_mangle] has twin effects: specify a particular name for C linkage purposes, and mark the symbol for DSO export. We want to do the latter but not the former. #54135 (comment) wants to do the former but not the latter. Can we separate those?

For our needs, ideally we’d mark rs_log with something like an #[dso_export] annotation. This would:

• Mark that symbol with the equivalent of __attribute__((visibility ("default"))), such that as it moves through the rlib, then staticlib, then the DSO, it is successfully exported from the DSO.
• But unlike #[no_mangle] it wouldn’t change the symbol name and it would remain callable by Rust.
• (The likely trickier bit) When building the final staticlib, determine if there are any such exported Rust APIs. If so, include whatever information is required by Rust to consider libbase.so to be a valid crate equivalent to a dylib. (I don’t know how Rust metadata is structured; whether this is just an extra few exported symbols or if there are entire linker sections within a dylib that would somehow need to be replicated. I strongly suspect the latter so I don’t even know if this is possible without changing the final C++ linker command).

Related work

#54135 requests something similar, but using #[used] on static variables - so I think it’s not quite the same thing.
dtolnay/cxx#219 proposes the workaround which we might need to do meanwhile (but isn’t ideal because, in the above example, RS::Log would be duplicated between two DSOs)

[dtolnay]

FYI @japaric @alexcrichton @retep998 in case you have a suggestion as the linkage experts.

Bottom line:

It’s a problem that #[no_mangle] has twin effects: specify a particular name for C linkage purposes, and mark the symbol for DSO export. We want to do the latter but not the former. #54135 (comment) wants to do the former but not the latter. Can we separate those?

[retep998]

If you want a shared library to be usable as a Rust crate it has to be built using the dylib crate type, because there is a lot of Rust specific metadata that gets bundled into the dylib. This is fundamentally at odds with compiling the Rust code into a staticlib and then linking that into a shared library. The dylib crate type is intended solely for Rust and its plugin model so it is unlikely to be expanded in this manner. Because linking against your shared library as a Rust crate is out of the question, there's also no need to preserve Rust name mangling so your concerns with #[no_mangle] are irrelevant.

The supported method is to export a function using the normal stable C ABI and then link against it as you would any other normal C ABI function. Using Rust types in that function signature will work if and only if you ensure that both sides are Rust where the Rust types comes from the exact same crate (as the Rust ABI is unstable, even a simple rebuild can change things)

[alexcrichton]

Controlling the visibility of a symbol is defintely something that's desired in Rust, but AFAIK it's just something no one's had enough time to sit down and design/RFC/etc. You might be able to play around on nightly with the #[linkage] attribute in one way or another.

The real problem here is that third bullet point, which is pretty nontrivial. The only thing I'd add is that in general it would only work for very simple datatypes. Even if the symbols were all hooked up you'd still have two Rust standard libraries linked in, and you can't, even with the same matching versions and all, pass datatypes between those two Rust standard libraries. There's some discussion of this on #63338 and related issues.

Theoretically to get this working you'll need to make sure all the Rust dependencies are shared. There's Rust crates (including libstd) used by the Rust code between libbase.so and libservices.so. All those shared Rust crates need to be included exactly once and exported from libbase.so which all of libservices.so would then use. That's just how this could work linkage-wise, though, I'm not really sure how this could be set up build-wise beyond hand-crafting all the rustc invocations with various flags.

[adetaylor]

Thank you very much for the comments, and yes I feared this would be difficult around that third bullet.

In our build system (which is not cargo-based) we could in theory ensure there's exactly one copy of each crate — in the example given this would mean ensuring that libstd is within libbase.so and only within libbase.so. But, to do this we would need to:

• add all the libstd metadata into libbase.so to make it behave like a dylib as well as a cdylib (and as @retep998 says, that's not currently conceivable - it would require an RFC, discussion, etc.)
• build a mechanism to mark our Rust symbols as exported from libbase.so (also needing an RFC)
• figure out a way to mark all the libstd symbols as visible, not just the symbols from our own code
• figure out how to avoid binary bloat, as we'd lose the advantages of the linker discarding unused bits of libstd

Even if worked through the first three points, the binary size growth from the final point feels like it would be more than just duplicating our own Rust code into lots of different cdylibs. As such, I'm going to see if I can work around it instead.

Thanks again for the comments!

I'm happy to leave this issue open or close it, whichever's preferred.

[hsivonen]

For Gecko, we'd need the opposite: Without changing the Rust code, from the top level of Rust compilation, making FFI symbols visible to the static link step that combines Rust and C++ into libxul without leaving the FFI symbols visible to outside libxul.

Should this issue be expected to result in that case getting addressed, or should I open a new issue for that?

[adetaylor]

@hsivonen I think you want the same as @RReverser here: #54135 (comment). (I'm not the best person to answer whether that should be in a new issue, I just wanted to make sure it was noted that you're not the only one to request that.)

[hsivonen]

Thanks. I filed a new issue.

[RReverser]

I believe both are essentially the same issue (a way to untangle linker visibility from no_mangle), but I guess no harm in tracking separately. Thanks!

[adetaylor]

Related:
#47384
#91504
#40289

For people looking for a way to export symbols from a staticlib. ld has --export-dynamic-symbol-list on linux and -exported_symbols_list on macos. The command I use on macos is:

clang -bundle -exported_symbols_list symbols.list -o libmyproject.so libmyproject.a

This works with -shared too. I haven't tested on linux, though.

[danakj]

For Chrome's purposes, we will be linking rlibs (in the future, --emit=obj or similar via #73632) together into a .so with clang. Thus no use of crate-type=staticlib. And marking a symbol as pub in Rust does appear to make the symbol visible in that .so file. It needs to be tested and confirmed on Windows though. Work on this is happening in https://crbug.com/1296156

[danakj]

Also related to controlling symbol visibility: #33221 and #37530

We're now at a point in Chromium where we have the opposite problem too, which is covered by the above two issues, that all Rust symbols are exported when we don't want them to be (no_mangle or not).

We really need some symbol visibility control for shared libs that is independent of pub and no_mangle.

[bjorn3]

Are you using the staticlib, dylib or cdylib crate type? Cdylib should only export #[no_mangle] symbols, dylib is expected to export all functions as it is meant to be used as regular dependency by other rust code. If you use staticlib see #104707.