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(b"awesome_function\0")，这个函数名称后面的\0的作用是什么？上面的例子如果如果使用lib.get(b"add\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库
