问题描述
通常我们在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类型。
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"]就可以了。