Dlaczego rdza nie tworzy polecenia dla openssl-sys v0.9.60 nawet po lokalnej instalacji?

Jan 04 2021

Napotykam błąd failed to run custom build command for openssl-sys v0.9.60podczas próby zbudowania mojego programu zardzewiałego. Oto main.rsi Cargo.tomlpliki.

main.rs

extern crate reqwest;

fn main() {
    let mut resp = reqwest::get("http://www.governo.mg.gov.br/Institucional/Equipe").unwrap();
    assert!(resp.status().is_success());
}

Cargo.toml

[package]
name = "get_sct"
version = "0.1.0"
authors = ["myname <myemail>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
reqwest = "0.10.10"

Zainstalowałem lokalnie openssl (jak zasugerowałem w tym pytaniu ), używając:

git clone git://git.openssl.org/openssl.git
cd openssl
./config --openssldir=/usr/local/ssl
make
make test
sudo make install

Wreszcie uciekłem export OPENSSL_DIR="/usr/local/ssl"

Zauważyłem, że miałem już instalację anacondy openssl, która znajdowała się w mojej domyślnej ścieżce. Aby zmienić domyślną ścieżkę openssl do instalacji github, uruchomiłem chmod -x MYPATH/anaconda3/bin/openssli teraz which opensslwraca /usr/local/bin/openssl.

Mam też zainstalowany pakiet pkg-config (zgodnie z sugestią w tym pytaniu ). Bieżące which pkg-configzwroty/usr/bin/pkg-config

Jednak po cargo runponownym uruchomieniu program wyświetla ten sam komunikat o błędzie. Oto cały komunikat o błędzie:

> cargo run
   Compiling openssl-sys v0.9.60
   Compiling tokio v0.2.24
   Compiling pin-project-internal v0.4.27
   Compiling pin-project-internal v1.0.2
   Compiling mime_guess v2.0.3
   Compiling url v2.2.0
error: failed to run custom build command for `openssl-sys v0.9.60`

Caused by:
  process didn't exit successfully: `/PACKAGEPATH/target/debug/build/openssl-sys-db18d493257de4f7/build-script-main` (exit code: 101)
  --- stdout
  cargo:rustc-cfg=const_fn
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
  X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
  OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
  X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
  OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
  X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR = /usr/local/ssl

  --- stderr
  thread 'main' panicked at 'OpenSSL library directory does not exist: /usr/local/ssl/lib', /home/lucas/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.60/build/main.rs:66:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build faile

Wygląda na to, że rdza szuka SSL w /usr/local/ssl/lib. W rzeczywistości /usr/local/sslna moim komputerze jest folder, ale go nie ma lib.

Co ja tu robię źle? Jak mogę sprawić, by moja lokalna instalacja openssl działała poprawnie z rdzą?

Odpowiedzi

4 ReinierTorenbeek Jan 04 2021 at 04:04

Nie mam doświadczenia w instalowaniu tego samodzielnie, ale mogę udzielić kilku wskazówek.

Przede wszystkim o Twoim wysiłku związanym z instalacją OpenSSL. Po sklonowaniu repozytorium nie wybierasz żadnej konkretnej gałęzi przed skonfigurowaniem i utworzeniem. Oznacza to, że budujesz mastergałąź, która jest ewoluującą wersją OpenSSL 3.0.0. To nie jest obsługiwana wersja zgodnie z dokumentacją skrzynki . Aby zbudować obsługiwaną wersję OpenSSL, będziesz musiał przełączyć się na jakąś gałąź lub tag 1.1.1. Alternatywnie możesz pobrać wersję 1.1.1 ze strony pobierania OpenSSL .

To powiedziawszy, nie wydaje się konieczne instalowanie OpenSSL ze źródła. W sekcji Automatyczne dokumentacja wyjaśnia, że ​​skrzynka może obsługiwać wszystkie rodzaje typowych instalacji OpenSSL. Jeśli to możliwe w Twoim przypadku, może być ci łatwiej to przestrzegać. Jeśli tak, to powinieneś usunąć ustawienie OPENSSL_DIRzmiennej środowiskowej, w przeciwnym razie spowoduje to (nadal) nadpisanie automatycznych mechanizmów skrzynki w celu znalezienia instalacji OpenSSL.

Jeśli nadal chcesz trzymać się ręcznej konfiguracji, to rzeczywiście powinieneś używać zmiennych środowiskowych i OPENSSL_DIRwydaje się to wygodna. Jednak nie oznacza to tego samego, co openssldirparametr użyty w poleceniu konfiguracji ./config --openssldir=/usr/local/ssl. Aby uzyskać szczegółowe informacje, sprawdź znaczenie tego parametru konfiguracyjnego . W rzeczywistości, czyli w skrzyni z OPENSSL_DIRsymboli odpowiada na --prefixustawienie (które nie skonfigurowano).

Problem, z którym się teraz spotykasz, polega na tym, że twoja OPENSSL_DIRzmienna wskazuje na twój katalog dla plików konfiguracyjnych OpenSSL, podczas gdy skrzynka oczekuje, że będzie wskazywać na górę rzeczywistego drzewa katalogów instalacyjnych OpenSSL (które w twoim przypadku wydaje się znajdować w /usr/local).