症狀
無法使用 cargo build
,因為可以在錯誤訊息中看到類似這樣的訊息
|
|
該訊息應會包括 curl
錯誤代碼 59 。
診斷以及修復
試著用 curl
和 wget
模擬下載的過程,但是不會出現這樣的錯誤。(特別注意使用 curl
的時候可以觀察到重新導向到 Amazon AWS ,真正相依包裹存放處的請求)
Google 的話勉強可以找到「試著用 strace
觀察看看」的建議,然而似乎無法觀察到很有建設性的東西。
不過值得注意的一點是,如果很多人都出現了類似的問題,那為什麼完全沒有看到完全一致的錯誤訊息呢?為什麼沒有人回報呢?如果這樣思考的話,只能假設是自己的作業系統這裡出了問題吧。
不過,為啥 curl
沒問題,然後 cargo
有問題呢?
總之百思不得其解。
不過在 YaST
的 Software Management
模組中,赫然發現自己有 libopenssl
卻沒有 libopenssl-devel
而是 libressl-devel
時有點驚嚇。
因為猜測這個事實可能是造成 cargo
無法運作的原因,因此把 libressl-devel
置換成 libopenssl-devel
,接著想要重新編譯 cargo
… 等等 cargo
卡住了不是嗎 Orz
好在,在 rustup
的資料夾中(~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/
)還有備用的 cargo
可以用,因此把該 cargo
覆蓋到 ~/.cargo/bin
之下的 cargo
,接著 cargo install cargo --force
就得到可以使用的 cargo
了。
(千秋的機器裡面 PATH
環境變數有包括 ~/.cargo/bin
)
修復方式大綱
因為問題出在 openssl
header 畢竟和 ressl
的 header 有差異,因此要替換成 openssl
的才行。
使用
libopenssl-devel
而非libressl-devel
從
rustup
的資料夾~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/
中調出備用的cargo
cargo install cargo --force
(當然,若滿足於備用cargo
的話也可以不做這步 XD)