Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking installation problem on Mac M1 #64

Open
Microraptoria opened this issue Dec 2, 2024 · 0 comments
Open

Blocking installation problem on Mac M1 #64

Microraptoria opened this issue Dec 2, 2024 · 0 comments

Comments

@Microraptoria
Copy link

Microraptoria commented Dec 2, 2024

Hello!

While trying to install it on a Mac 15.0 Sequoia (M1 Chip) with Rust 1.83.0, I've faced the following error:

--- stdout
  MacOS detected. We will check if you have either the MacPorts or Homebrew package managers.
  Checking for MacPorts...
  Macports not found.
  Checking for Homebrew...
  'brew' executable detected at "/opt/homebrew/bin/brew\n"
  Proceeding with installation assuming Homebrew is your package manager

  --- stderr
  thread 'main' panicked at /Users/blep/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rsmgclient-2.0.2/build.rs:101:14:
  called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }

After investaging a bit by myself, I was able to fix it "quickly and dirty" by tweaking your code. When looking at the aforementioned file (build.rs), I get:

let mut openssl_dirs = std::fs::read_dir(PathBuf::new().join(path_openssl))
            .unwrap()

(a bit more about this later). Just above, I see that you check the installation of OpenSSL:

let path_openssl = if cfg!(target_arch = "aarch64") {
            "/opt/homebrew/Cellar/[email protected]"
        } else {
            "/usr/local/Cellar/[email protected]"
        };

I've changed from [email protected] to openssl@3 (which is installed on my machine). Note that for MacPorts you check the installation of openssl3. So, I bypassed the error. 😁

Anyway, the error comes from the fact that std::fs::read_dir returns a Result that you bypass using an unwrap. So, if [email protected] is effectively not installed on the client's machine (which was the case for me), it explodes. 💥

Moreover, even if it's not recommended, if I try to install [email protected] through brew, I get:

Error: [email protected] has been disabled because it is not supported upstream! It was disabled on 2024-10-24. 

Hence the blocking error. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant