Open devernay opened 2 years ago
Any suggestions for an alternative check would be most welcome, but deleting it isn't an option as that will break for other libraries.
The fix seems to be to simply use the versioned path: https://github.com/cl-plus-ssl/cl-plus-ssl/pull/115 Required both for libcrypto and libssl, it seems
and the versioned path is only required for the system-provided openssl.
See this comment: setting the environment variable OPENSSL_PREFIX
to a non-existing dir (or to a directory where there is a non-system SSL) fixes it.
It seems like Apple has its own patched openssl, which checks that it's loaded in a "safe" way
See this comment: setting the environment variable OPENSSL_PREFIX to a non-existing dir (or to a directory where there is a non-system SSL) fixes it.
That sounds like something that should be fixed in Net::SSLeay's Makefile.PL, instead of in MakeMaker itself.
It seems like Apple has its own patched openssl, which checks that it's loaded in a "safe" way
How on-brand, taking something that has worked everywhere for years and breaking it :expressionless:
Not just Net::SSLeay, e.g. Crypt::OpenSSL::RSA appears to crash, caused by the same issue (reported)
--> Working on Crypt::OpenSSL::RSA
Fetching http://cpan.metacpan.org/authors/id/T/TO/TODDR/Crypt-OpenSSL-RSA-0.31.tar.gz
-> OK
Unpacking Crypt-OpenSSL-RSA-0.31.tar.gz
Copying Crypt-OpenSSL-RSA-0.31.tar.gz to [...]
Entering Crypt-OpenSSL-RSA-0.31
Checking configure dependencies from META.json
Checking if you have Crypt::OpenSSL::Guess 0.11 ... No
Checking if you have ExtUtils::MakeMaker 7.20 ... Yes (7.62)
==> Found dependencies: Crypt::OpenSSL::Guess
[...]
Configuring Crypt-OpenSSL-RSA-0.31
Running Makefile.PL
Warning: prerequisite Crypt::OpenSSL::Random 0 not found.
Checking if your kit is complete...
Looks good
WARNING: /opt/homebrew/Cellar/perl/5.34.0/bin/perl is loading libcrypto in an unsafe way
-> N/A
-> FAIL No MYMETA file is found after configure. Your toolchain is too old?
-> FAIL Configure failed for Crypt-OpenSSL-RSA-0.31. [...]
Any suggestions for an alternative check would be most welcome, but deleting it isn't an option as that will break for other libraries.
@Leont can you please elaborate? I'm having trouble connecting the original submissions back to the original problem.
Without this fix, it will erroneously believe that system provided libraries aren't available at all.
Sorry, I don't follow. Every other OS is handled in this function by searching the file system in various locations. What's changed with Mac that makes this approach difficult/untenable?
Every other OS is handled in this function by searching the file system in various locations. What's changed with Mac that makes this approach difficult/untenable?
On recent versions of Mac a lot of system libraries don't actually exist on the filesystem (or at least not in their usual place), but the linker (including dlopen) will pretend they do. The other half of this fix was !18407.
Any suggestions for an alternative check would be most welcome, but deleting it isn't an option as that will break for other libraries.
Did you consider _dyld_shared_cache_contains_path?
https://github.com/search?q=org%3Apython+_dyld_shared_cache_contains_path&type=code
Did you consider _dyld_shared_cache_contains_path?
I haven't, I don't think we can use it from MakeMaker anyway as it's a C function
This change: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8b924f65a0485266822c904e11698f95019bc467
which was made made to work a bit later with https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/21a441da515d55654bca4971f21ad2550de069d2
Seems to be considered as an unsafe way to load openssl on macOS monterey, and crashes perl.
Note that Monterey ships with version 7.34 of this module, so only homebrew and MacPorts users (who install 7.62) are affected: