New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-exporting C symbols for cdylib #2771
Comments
Does making them |
@petrochenkov Declaring |
Can we please have some focus brought to this. For many applications which combine both C and Rust and are trying to create a |
It seems clear that we need this functionality in one form or other. Ideally we'd have an RFC to determine who this should be implemented exactly. @aturon, how do we handle this, it being the impl period now? Or maybe we can decide on a straightforward way how to express this without an RFC. |
I'll leave this nominated for now so it doesn't fall off the radar. Hopefully we'll have a clearer picture on how to proceed before the next dev-tools meeting. |
I think we could approach the procedural issue here in a few ways:
It's not like RFCs are prohibited per se, more that we're trying to focus the teams on executing already-planned work. This is small enough that it's probably not a big distraction. I do think that in general this area of Rust could use more design focus, FWIW. |
Currently the recommended way to export a function that you define yourself from a
The crate root being the root of the |
cc @rust-lang/lang, adding this to our list of issues that need to be triaged. |
We discussed this one in the lang team meeting. This does need an RFC; how quickly that progresses will depend on how smoothly and non-bikesheddy the RFC goes. The approach of making symbols public if Also, we should stop automatically exporting such symbols from a |
Oh, this is great. What is done now (if I remember correctly), e.g. heuristic-based link-time visibility based on sum of factors like crate type, ABI (non- |
I do think it'd be nice to have a broader RFC that explicitly defines when symbols should be exported, across all use-cases. |
I just stumbled over this. Is there any workaround that we can use in the meantime? In the worst case I could wrapp all 3rd party functions with my own: extern crate saltyrtc_client_ffi;
pub type salty_event_loop_t = saltyrtc_client_ffi::salty_event_loop_t;
#[no_mangle]
pub extern "C" fn salty_event_loop_new() -> *mut salty_event_loop_t {
saltyrtc_client_ffi::salty_event_loop_new()
} ...but I hope there's a better way than this. If not, this is really a stumbling block when trying to reuse code from FFI compatible crates... |
I just encountered this issue at work. We've got a @dbrgn for now I've found a really crummy workaround.... I'm creating a macro which will manually re-export the symbols. So you "only" need to call It feels horrible, but it works... #[doc(hidden)]
#[macro_export]
macro_rules! export_c_symbol {
(fn $name:ident($( $arg:ident : $type:ty ),*) -> $ret:ty) => {
#[no_mangle]
pub unsafe extern "C" fn $name($( $arg : $type),*) -> $ret {
$crate::error_handling::$name($( $arg ),*)
}
};
(fn $name:ident($( $arg:ident : $type:ty ),*)) => {
export_c_symbol!(fn $name($( $arg : $type),*) -> ());
}
}
/// As a workaround for rust-lang/rust#6342, you can use this macro to make sure
/// the symbols for `ffi_utils`'s error handling are correctly exported in your
/// `cdylib`.
#[macro_export]
macro_rules! export_error_handling_functions {
() => {
export_c_symbol!(fn clear_last_error());
export_c_symbol!(fn last_error_length() -> ::libc::c_int);
export_c_symbol!(fn last_error_length_utf16() -> ::libc::c_int);
export_c_symbol!(fn error_message_utf8(buf: *mut ::libc::c_char, length: ::libc::c_int) -> ::libc::c_int);
export_c_symbol!(fn error_message_utf16(buf: *mut u16, length: ::libc::c_int) -> ::libc::c_int);
};
} |
@Michael-F-Bryan thanks. yeah, there's probably currently no way around wrapping these functions. by the way, you should try to avoid two |
Yep. The first time I ran the test suite with that macro I got lots of linker errors due to duplicate symbols. I "fixed" that by removing the Interestingly, I never got the "duplicate symbols" error when compiling the DLL in release mode. I'm assuming rustc/LLVM inlines the original functions and then strips out their now "unused" function symbols before they get to the linking stage. |
It doesn't happen when linking together two libraries with rustc, but it happened to me when trying to link two independent shared libraries (compiled from Rust) into an iOS app. There might be a way to extract the Rust stdlib into a separate shared library (similar to the way it's done with libc, if I understand this correctly), but I haven't found a way to do this so far. But that's probably offtopic here :) |
Stepped into this issue as well. Unfortunately the solution with function wrapper does not work for me as I have to reexport arrays. |
The workaround does not work for me either as I need to (re)export variadic functions which cannot be defined in Rust. |
@tanriol While it doesn't address your immediate issue, in case you haven't already seen it, #2137 and rust-lang/rust#44930 may help you in the future. |
This required some shenanigans with the probestack definition to get it exported in the final `lucet_runtime.so`. I left a TODO in the code to revert it once [this Rust issue](https://github.com/rust-lang/rust/issues/36342) is fixed.
Moving the stack probe into the compiled Lucet modules lets us dodge Rust's current inability to reexport dynamic symbols (see <https://github.com/rust-lang/rust/issues/36342>). It loses a small amount of fidelity that we got with stack overflow traps previously, as we can't distinguish a stack overflow originating in the stack probe from anywhere else. The C test suites are now parameterized over region, much like the Rust test suites.
I encountered this issue on Linux using rust 1.33.0. The trick to set |
I just ran into, and spent hours, debugging this. :( In my case I can trivially wrap it but it'd be nice if I could tell Rust not to throw away my symbol :( |
So right now it is not possible to re-export, for example, |
When building a cdylib, Rust currently doesn't export public symbols on Linux if they come from a dependency. However, enabling LTO gets around this by performing the filtering step after the merging. rust-lang/rfcs#2771
When building a cdylib, Rust currently doesn't export public symbols on Linux if they come from a dependency. However, enabling LTO gets around this by performing the filtering step after the merging. rust-lang/rfcs#2771
When building a cdylib, Rust currently doesn't export public symbols on Linux if they come from a dependency. However, enabling LTO gets around this by performing the filtering step after the merging. rust-lang/rfcs#2771
In an extern block, C symbols can be imported to Rust. When building Rust library into
dylib
, the symbols stay visible and can be used from C. However, when building into newly introducedcdylib
, the imported C symbols are no longer visible. I am not aware of a mechanism to re-export the C symbols.The text was updated successfully, but these errors were encountered: