How to expose extern function like a proxy

help
1

e.g. I have

extern "C" {
    pub fn LZ4_versionNumber() -> c_int;
}

Then I want to expose the same function for FFI when I build dynamic lib with cargo

#[no_mangle]
pub extern "C" fn ffi_LZ4_versionNumber() -> c_int {
    return unsafe { LZ4_versionNumber() };
}

My question is that, is there a way to directly expose the function with the same name? Something like

extern "C" {
    #[no_mangle]
    #[extern_c]
    pub fn LZ4_versionNumber() -> c_int;
}

So that LZ4_versionNumber will appear in dynamic symbol table and be callable from other launguages. Thanks!

2

See this page, which has this example:

#[no_mangle]
pub extern fn callable_from_c(x: i32) -> bool {
    x % 3 == 0
}
3

Thanks for the reply! But this is not what I'm looking for. What I look for is to directly expose the original C api and keep its original symbol name in final dylib built from rust. Does that make sense?

4

Is there some sort of separate namespace going on here? I'd assume that the original symbol is already accessible at that name as your Rust code is accessing it at that name?

5

Say original lib (liblz4.a) is statically linked with rust, output dylib produced by rust will not perserve the orignal symbol name in symbol table

6

Assume liblz4.a is built from source via cc-rs in build.rs

7

I don't think this is possible without a proxy rust function that isn't inlineable without LTO.

8

Even with a proxy function, it seems that I cannot expose the original symbol name with the proxy function, any workaround?

9

If the original C symbol really has mysteriously disappeared (it sounds like you're staticly linking the symbol in), then I don't think you can re-add it. What are you trying to do, perhaps there's an alternative solution?

E.g. as a hack: since you're building the library from source, you could rename the symbol in the C source, which would allow you to create your own symbol of that name?

10

Basically I want to ues rust to build some C source code and expose original C APIs (already well documented) to other VM base languages, also I can make some extensions with rust code. Rust works mostly as a cross-platform build tool here, also provides the capability of extending the C code (in rust) without touching it (C code). Does that make sense?

11

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