症狀
無法使用 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/中調出備用的cargocargo install cargo --force（當然，若滿足於備用cargo的話也可以不做這步 XD）
