通常我们在rust项目中引入第三方依赖包时,会直接指定包的版本,这种方式指定后,Cargo在编译时会从crates.io这个源中下载这些依赖包。
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
j4rs = 0.15.3
比如这里我们就在项目中引用了j4rs
这个包,这个包的主要作用是可以实现从Rust代码中调用Java代码。
博主在使用这个包时发现,crates.io上发布的最新版本0.15.3
有bug,这个版本依赖了logback的新版本,而logback的新版本使用了Java 11进行编译。这就导致了j4rs 0.15.3
这个版本不支持Java 8。
于是博主在github上向作者提了issue,作者很快就做了修改,并更新到了github项目的master分支上。然而作者却没有向crates.io推送最新版本的包,我们想用最新版本就不能直接引用crates.io上的版本。
想要解决这个问题也很简单,我们可以直接引用源码作为依赖,主要有一下两种方式。
Cargo支持直接引用git最新版本的代码
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
j4rs = { git = "https://github.com/astonbitecode/j4rs" }
引用本地源码
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
j4rs = { path = "../j4rs/rust" }
当我们引用三方包的源码后,编译时Cargo也会根据三方包的Cargo配置编译这些三方包的源码,然后把编译的结果输出到本项目的target/[debug/release]/deps目录下,这样本项目就可以使用这些三方包了。
博主在引用j4rs
这个三方包时遇到了这个问题:release编译时,编译器提示,j4rs编译的输出命名冲突。
查看j4rs
源码中的Cargo.toml
文件
[package]
name = "j4rs"
version = "0.15.4"
...
[badges]
travis-ci = { repository = "astonbitecode/j4rs", branch = "master" }
[lib]
name = "j4rs"
crate-type = ["rlib", "cdylib"]
path = "src/lib.rs"
可以发现crate-type
这里配置了两种编译结果crate类型。
bin: 二进制可执行 crate,编译出的文件为二进制可执行文件。必须要有 main 函数作为入口。这种 crate 不需要在 Cargo.toml 中或 --crate-type 命令行参数中指定,会自动识别。
lib: 库crate。它其实并不是一种具体的库,它指代后面各种库 crate 中的一种,可以认为是一个代理名称(alias)。通常来讲,如果什么都不配置,默认指的是 rlib, 会生成 .rlib 的文件。
dylib: 会在编译的时候,生成动态库(Linux 上为 .so, MacOS 上为 .dylib, Windows 上为 .dll)。动态库是平台相关的库。动态库在被依赖并链接时,不会被链接到目标文件中。这种动态库只能被 Rust 写的程序(或遵循 Rust 内部不稳定的规范的程序)调用。这个动态库可能依赖于其它动态库(比如,Linux 下用 C 语言写的 PostgreSQL 的 libpq.so,或者另一个编译成 "dylib" 的 Rust 动态库)。
staticlib: 静态库。编译会生成 .a 文件(在 Linux 和 MacOS 上),或 .lib 文件(在 Windows 上)。编译器会把所有实现的 Rust 库代码以及依赖的库代码全部编译到一个静态库文件中,也就是对外界不产生任何依赖了。这特别适合将 Rust 实现的功能封装好给第三方应用使用。
cdylib: C规范动态库。与 dylib 类似,也会生成 .so, .dylib 或 .dll 文件。但是这种动态库可以被其它语言调用(因为几乎所有语言都有遵循 C 规范的 FFI 实现),也就是跨语言 FFI 使用。这个动态库可能依赖于其它动态库(比如,Linux 下用 C 语言写的 PostgreSQL 的 libpq.so)。
rlib: rlib 是 Rust Library 特定静态中间库格式。如果只是纯 Rust 代码项目之间的依赖和调用,那么,用 rlib 就能完全满足使用需求。rlib 实现为一个 ar 归档文件。rlib 中包含很多 metadata 信息(比如可能的上游依赖信息),用来做后面的 linkage。可以指定生成 rlib,但是一般没必要设置,因为默认 lib 就是 rlib。rlib 是平台(Linux, MacOS, Windows ...)无关的。
proc-marco: 这种 crate 里面只能导出过程宏,被导出的过程宏可以被其它 crate 引用。
根据文档j4rs
设置的两种crate类型,rlib
表示rust本身定义的中间结果,如果rust代码互相引用,直接使用这种类型就可以。cdylib
是符合c标准的动态链接库,这种方式编译的结果可以被其他语言作为动态库使用。
当我们进行release编译时,Cargo会根据配置帮我们编译j4rs
这两种格式的目标输出。
这时Cargo就会提示我们输出了一个libj4rs.rlib
文件,又要输出一个libj4rs.so
文件,这两个库文件名字一样,冲突了。这会导致我们的代码在链接j4rs
时无法选择应该使用哪个库。
因此解决方法是:只要在j4rs
的源码里将Cargo.toml
文件中的配置crate-type = ["rlib", "cdylib"]
改为crate-type = ["rlib"]
就可以了。
日志是应用程序的重要组成部分。无论是服务端程序还是客户端程序都需要日志做为错误输出或者业务记录。在这篇文章中,我们结合log4rs聊聊rust 程序中如何使用日志。