网站信息系统,意派h5制作平台官网,唯品会网站建设目标,高端网站定制公司no_mangle 不要改标识符
首先是认识这个标注#xff1a;mangle#xff0c;英文的含义“撕裂、碾压”。我第一次把这个单次误以为是manage#xff0c;说实话两个单词还挺像的。
RUS中函数或静态变量使用#[no_mangle]这个标注属性后#xff0c;编译器就不会修改它们的名字了…no_mangle 不要改标识符
首先是认识这个标注mangle英文的含义“撕裂、碾压”。我第一次把这个单次误以为是manage说实话两个单词还挺像的。
RUS中函数或静态变量使用#[no_mangle]这个标注属性后编译器就不会修改它们的名字了。mangling是一个特殊的编译阶段在这个阶段编译器会修改函数名称来包含更多用于后续编译步骤的信息但通常也会使得函数名称难以阅读。
举个例子一个叫do_something的函数可能会被改名为_ZN10mycrate3foo10do_somethingEi或者其它相似的名字。几乎所有程序语言的编译器都会以稍微不同的方式来改变函数名称。
mangling可以避免不同包的函数同名冲突但有些时候我们也需要去禁止mangling操作比如下面的场合
暴露RUST函数给别的语言调用比如C语言。这里我们就需要变体保留原始的名称定义必须匹配具体函数签名的入口或者外部接口
为了让其它语言正常地识别RUST函数我们必须禁用RUST函数的改名功能。通过给函数增加#[no_mangle] 我们就可以明确告诉RUST将排除mangling操作
#[no_mangle]
pub extern fn do_something(x: i32) {// ...
}总结一句当你需要将RUST函数暴露给其它语言或者其它运行环境使用时#[no_mangle] 需要用来保证我们的函数依旧是原来的名称。
libloading 动态加载能力
我们编译一个动态库动态库中声明下面的方法
#[no_mangle]
pub fn add(left: usize, right: usize) - usize {left right
}#[no_mangle]
pub fn println(str: str) {println!({}, str)
}pub fn print_hello() {println!(Hello)
}libloading允许我们在程序中加载外部共享的.so文件直接使用.so中存在的函数或者静态变量。libloading提供了一个跨平台的接口来加载外部库并使用其中定义的内容。但程序在不同的平台上执行可能会存在一些差异这点libloading是不做保证的。
将libloading库加入我们的项目依赖中
[dependencies]
libloading 0.8文档的说明案例中提到了生命周期保证编译器会确保从外部包中加载的函数生命周期不会长于外部包的生命周期。 程序正常执行输出结果3。在这个过程中遇到3个有待解释的问题
我尝试加载.rlib的静态库文件方法Library::new会触发报错extern C 这个声明的作用是什么在编译.dylib的过程中并没有引入任何C代码官方示例指定函数名称时使用lib.get(bawesome_function\0)这个函数名称后面的\0的作用是什么上面的例子如果如果使用lib.get(badd\0)也是可以正常执行的。
.rlib被当做dependences来使用
staticlib和cdylib包类型主要用作独立的二进制文件可以通过独立其C API使用。一个RUST库可以通过C API使用另一个RUST库。
正常来说我们使用cargo来构建我们的应用并在Cargo.toml下的[dependencies]中添加我们的依赖。但如果我们想去使用一些没有发布到crates.io的库我们也可以在[dependencies]中指定依赖的路径。
[dependencies]
testing { path ./path/to/testing }Cargo将会确保路径指定的库已经被编译成了rlib文件。在运行时执行cargo build --verbose可以查看详细的过程。
说白了拿GO语言做类比.rlib这个格式类似于我们在本地新增加了一个代码仓库通过import来导入了这个新的仓库。
extern C
这个问题可以查看我的另一篇博客外部函数接口FFI虽然只是RUST到RUST的依赖库调用但两个依赖库是按照C ABI的协议来进行交互的。因为RUST内存结构的不安全性我们严格需要这个限定。
安全传递结构体类型
我们尝试在动态链接库间传递结构体类型但因为RUST不安全的内存布局摆在我们面前的就只剩下两条路
使用C ABI和libloading的原始动态链接尝试使用abi_stable库
