Error: problem with dependency scan of '/usr/local/lib/libcrypto.dylib' with '/usr/local/opt/openssl@3/lib/libcrypto.3.dylib' please report the bug about nuitka HOT 5 CLOSED

Sorry @kayhayen , but I cannot reproduce this on arm64 macOS (specifically mac mini, having Homebrew on PATH).

I did a quick test based on runners using Github Actions. According to Github Document, macos-11, macos-12 and macos-13 are x86_64-based of macOS, while macos-14 is arm64-based of macOS. Then just define job steps to run the exact build procedure this issue addressed before on the OS-matrix. The test result is here.

As you can see, for jobs on macos-14, which have Homebrew in PATH (verified by Get Homebrew version step, the same on other OS), but nuitka didn't give any errors. However for jobs on x86_64-based macOS, the job succeeded with nuitka 1.8.6, but not with nuitka 1.9 and nuitka 2.2.1, and gave the error this issue aimed to report.

Does that mean this is an exception specifically for x86_64-based macOS? Should I continue on this issue or reopen another?

from nuitka.

It seems you have Homebrew in PATH, don't do that. For CPython, Nuitka will pick up system DLLs and believe this one to be necessary.

from nuitka.

@LorenEteval @kayhayen

This fixed it for me with the Github provided runners, given that you do this before your Nuitka step:

      # Remove problematic brew libs if Intel Mac
      - name: Remove problematic brew libs
        run: |
          brew remove --force --ignore-dependencies openssl@3
          brew cleanup openssl@3
        if: runner.os == 'macos' && matrix.arch == 'i386'

from nuitka.

With Homebrew, it's "lib" directory has to be added, and for amd64, this is clearly separated from the rest of the OS, but I am not so sure for x86_64, there it was probably very dirty. Since Homebrew is not what is recommended for portable distributions anyway, I don't think I will want to make it work if it's effort to pull hairs between OS and Homebrew DLLs not being clearly sorted. I think CPython should be used rather than Homebrew, since that gives maximum portability. Homebrew typically is not backward portable, CPython and PyPI are better at that, maybe, although I wouldn't swear on it.

from nuitka.

I am tempted to disallow standalone on Homebrew with x86_64, since it's a trap only, but maybe I am all wrong, and the /usr/local/lib is not an OS folder at all, is it?

from nuitka.