問題描述
通常我們在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"]就可以了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/549013.html
標籤：其他
上一篇：Java 處理重復提交問題
下一篇：記憶體管理：判斷物件是否存活