p5.28-net-ssleay failed to compile under Monterey (21A5304g)

[ilTofa (Giacomo Tufano)]

I reinstalled MacPorts from source under Monterey and git installation fails with p5.28-net-ssleay failing to compile. I'm unsure if a ticket can be opened on a beta macOS version, if this was not allowed please feel free to close it (and accept my apologies). Compilation logs are attached.

[ilTofa (Giacomo Tufano)]

Compilation log for the port p5.28-net-ssleay

[reneeotten (Renee Otten)]

please remember not to discuss pre-releases here. Do you see the same problem on a released macOS version?

[ilTofa (Giacomo Tufano)]

Uh, sorry Renée, no, it compiles correctly on BigSur, I got the problem during a manual migration (and a couple of others too in other packages). I don't think this impacts any NDA but the FAQs are very clear, my apologies. Should I close the ticket now?

[ryandesign (Ryan Carsten Schmidt)]

The fact that perl5.28 crashed is presumably a result of the preceding warning that perl5.28 "is loading libcrypto in an unsafe way". You could check the crash log for corroboration of that. Such warnings started appearing in Big Sur already, as discussed for example ​on stackoverflow. So it's interesting to hear that there is perhaps a new permutation of this problem on Monterey. Or perhaps it is just a bug in your beta of Monterey that will be resolved before the first stable version is shipped. If you find that the problem goes away, you can close the ticket then. If you learn that this is an intentional change of behavior that will stay and you know of a fix, you can let us know or file a pull request.

[AP1010]

This has something to do with OPENSSL_PREFIX env variable. Altering the Portfile and setting OPENSSL_PREFIX=/opt/local/lib/openssl@1.1 allowed me to successfully build p5.28-net-ssleay

[steven-michaud (Steven Michaud)]

I ran into the same problem and found a workaround: Change the 'perl5.default_branch' setting in git's 'Portfile' from '5.28' to '5.30'. This makes git use Perl 5.30 instead of 5.28. For some reason Perl 5.30 builds just fine.

The "loading libcrypto in an unsafe way" error happens when something tries to load macOS's own unversioned 'libcrypto.dylib'. It doesn't happen loading MacPorts' 'libcrypto.dylib', versioned or unversioned. Only the macOS copy triggers this error. This has been true at least since macOS 11 (BigSur). For some reason MacPorts' Perl 5.28 tries to load the macOS copy -- even when a MacPorts copy already exists in '/opt/local/lib'. This doesn't happen with Perl 5.30.

Edit: And now I realize that using OPENSSL_PREFIX=/opt/local/lib/openssl@1.1 is another way to work around the same problem.

[ilTofa (Giacomo Tufano)]

I can confirm that altering the Portfile for p5-net-ssleay to contain OPENSSL_PREFIX=/opt/local/lib/openssl@1.1 is a valid workaround and git build successfully (this is with Monterey beta 7 and Xcode 13 non beta, with the expected warning about "macOS 12 SDK does not appear to be installed").

Before trying the altering of the Portfile I tried to compile git with perl 5.30 and 5.32 via "port install git +perl5_30" (and *5_32), but I got the same error as with Perl 5.28

:info:configure *** Found OpenSSL-1.1.1l installed in /opt/local
:info:configure *** Be sure to use the same compiler and options to compile your OpenSSL, perl,
:info:configure     and Net::SSLeay. Mixing and matching compilers is not supported.
:info:configure Checking if your kit is complete...
:info:configure Looks good
:info:configure WARNING: /opt/local/bin/perl5.30 is loading libcrypto in an unsafe way
:info:configure sh: line 1: 24028 Abort trap: 6           /opt/local/bin/perl5.30 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang"
:info:configure Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5-net-ssleay/p5.30-net-ssleay/work/Net-SSLeay-1.90" && /opt/local/bin/perl5.30 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang" 
:info:configure Exit code: 134
:error:configure Failed to configure p5.30-net-ssleay: configure failure: command execution failed
:debug:configure Error code: NONE

[breiter (Brian Reiter)]

I ran into this problem on the production monterey 12.0.1 when installing git. The above solution of setting OPENSSL_PREFIX worked. I used the +perl5_32 variant.

--- Portfile.ori	2021-10-26 08:48:57.000000000 +0200
+++ Portfile	2021-10-26 08:52:59.000000000 +0200
@@ -25,7 +25,7 @@
     depends_lib-append \
                     path:lib/libssl.dylib:openssl
 
-    configure.env   OPENSSL_PREFIX=${prefix}
+    configure.env   OPENSSL_PREFIX=${prefix}/lib/openssl@1.1
 
 # clang: error: unknown argument: '-fstack-protector-strong'
     if {[string match *clang* ${configure.compiler}]} {

[reneeotten (Renee Otten)]

In cbbf887681f24dfd859d1466fcf3245239969382/macports-ports (master):

p5-net-ssleay: use openssl PG

Closes: #63415

[breiter (Brian Reiter)]

The proposed fix Revision 1 in ​https://github.com/macports/macports-ports/commit/cbbf887681f24dfd859d1466fcf3245239969382 does not work.

debug:configure system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-net-ssleay/p5.32-net-ssleay/work/Net-SSLeay-1.90" && /opt/local/bin/perl5.32 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang" 
:info:configure Do you want to run external tests?
:info:configure These tests *will* *fail* if you do not have network connectivity. [n] n
:info:configure *** Found OpenSSL-1.1.1l installed in /opt/local/libexec/openssl11
:info:configure *** Be sure to use the same compiler and options to compile your OpenSSL, perl,
:info:configure     and Net::SSLeay. Mixing and matching compilers is not supported.
:info:configure Checking if your kit is complete...
:info:configure Looks good
:info:configure WARNING: /opt/local/bin/perl5.32 is loading libcrypto in an unsafe way
:info:configure sh: line 1: 79535 Abort trap: 6           /opt/local/bin/perl5.32 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang"
:info:configure Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-net-ssleay/p5.32-net-ssleay/work/Net-SSLeay-1.90" && /opt/local/bin/perl5.32 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang" 
:info:configure Exit code: 134
:error:configure Failed to configure p5.32-net-ssleay: configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
:debug:configure     while executing
:debug:configure "$procedure $targetname"

However using OPENSSL_PREFIX=${prefix}/lib/openssl@1.1 instead of OPENSSL_PREFIX=[openssl::install_area] does work.

[reneeotten (Renee Otten)]

Replying to breiter:

The proposed fix Revision 1 in ​https://github.com/macports/macports-ports/commit/cbbf887681f24dfd859d1466fcf3245239969382 does not work.

However using OPENSSL_PREFIX=${prefix}/lib/openssl@1.1 instead of OPENSSL_PREFIX=[openssl::install_area] does work.

using ${prefix}/lib/openssl@1.1 does not make sense to me as that doesn't actually exists. So if my fix doesn't work for you (it does work locally for me) then I don't know and will leave it to others who know Perl.

[Schamschula (Marius Schamschula)]

Still broken for me (under Monterey Intel, Xcode 13.1):

--->  Configuring p5.32-net-ssleay
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5-net-ssleay/p5.32-net-ssleay/work/Net-SSLeay-1.90" && /opt/local/bin/perl5.32 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang" 
Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n] n
*** Found OpenSSL-1.1.1l installed in /opt/local/libexec/openssl11
*** Be sure to use the same compiler and options to compile your OpenSSL, perl,
    and Net::SSLeay. Mixing and matching compilers is not supported.
Checking if your kit is complete...
Looks good
WARNING: /opt/local/bin/perl5.32 is loading libcrypto in an unsafe way
sh: line 1: 21174 Abort trap: 6           /opt/local/bin/perl5.32 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang"
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5-net-ssleay/p5.32-net-ssleay/work/Net-SSLeay-1.90" && /opt/local/bin/perl5.32 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang" 
Exit code: 134

[mf2k (Frank Schima)]

Me too with Monterey Intel and Xcode 13.1. Will attach my log.

[reneeotten (Renee Otten)]

just to be clear, I thought my change would fix the issue. But if that's not the case or perhaps just Moneterey related (as it works fine on Catalina) then someone else will have to look into it - I have no intention to work on this.

[devernay (Frédéric Devernay)]

This is definitely Monterey related, and it's blocking building any port that uses git, because p5.28-net-ssleay is a required dependency:

$ sudo port install git
--->  Computing dependencies for git
The following dependencies will be installed:
 p5.28-io-socket-ssl
 p5.28-net-smtp-ssl
 p5.28-net-ssleay
 p5.28-term-readkey
Continue? [Y/n]:

Unless there's a workaround (e.g., to use the system git), it prevents any reasonable MacPorts installation on that system.

[devernay (Frédéric Devernay)]

Workaround: port uninstall p5.28-extutils-makemaker before port install p5.28-net-ssleay does it! Hint came from ​https://stackoverflow.com/questions/67003619/mac-m1-homebrew-perl-carton-netssleay-is-loading-libcrypto-in-an-unsafe-way

[devernay (Frédéric Devernay)]

And the faulty line from the current version is: ​https://metacpan.org/release/BINGOS/ExtUtils-MakeMaker-7.62/source/lib/ExtUtils/Liblist/Kid.pm#L178

My guess is ​https://metacpan.org/pod/ExtUtils::MakeMaker will soon get an upstream upgrade to fix that issue

[devernay (Frédéric Devernay)]

Filed an upstream bug ​https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/404

if you really need p5-extutils-makemaker, you could safely delete the following section from Kid.pm:

            elsif ( $^O eq 'darwin' && require DynaLoader && defined &DynaLoader::dl_load_file
                && DynaLoader::dl_load_file( $fullname = "$thispth/lib$thislib.$so", 0 ) )
            {
            }

The port for this bug should probably be changed to p5-extutils-makemaker

[AP1010]

Replying to reneeotten:

just to be clear, I thought my change would fix the issue. But if that's not the case or perhaps just Moneterey related (as it works fine on Catalina) then someone else will have to look into it - I have no intention to work on this.

Here is the fun part: what seems to fix it on Monterey is to set the

OPENSSL_PREFIX

to a non existing directory. This could be

 ${prefix}/lib/openssl@1.1

but it could also be:

 /I_am/not/there

With this setting, it builds.

[ednl (Ewoud Dronkert)]

I also have this issue, comment to subscribe. Workaround did work.

[Schamschula (Marius Schamschula)]

I set configure.env OPENSSL_PREFIX=/dev/null and that worked for me!

[reneeotten (Renee Otten)]

has duplicate #63686

[markmentovai (Mark Mentovai)]

I have a pull request that fixes this (and explains the problem):

​https://github.com/macports/macports-ports/pull/12704

(You might notice that the AuthorDate is 2021-06-08. Sorry I’ve hoarded this for so long, but I didn’t want to openly discuss dyld misfeatures in an unreleased Apple OS. I had hoped that they’d fix it before release.)

[Gregory-Gelfond (Gregory Gelfond)]

If and when that goes in that would lead to a lot of applause on my end :-)

[markmentovai (Mark Mentovai)]

In 911ba56d1268af44c9d2a731443443f7f3d4d8e5/macports-ports (master):

p5-net-ssleay: Work around macOS 12 dyld misfeature

Attempting to load a file that does not exist (here,
/opt/local/libcrypto.dylib) will search the dyld shared cache by
filename, and return /usr/lib/libcrypto.dylib from the dyld shared
cache. That module is poisoned and has a load-time initializer that
calls abort(). There is no reason to attempt to load from /opt/local as
opposed to /opt/local/lib.

mark@sweet16 zsh% sw_vers
ProductName: macOS
ProductVersion: 12.0.1
BuildVersion: 21A559
mark@sweet16 zsh% /opt/local/bin/perl5.28 Makefile.PL
Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n]
* Found OpenSSL-1.1.1l installed in /opt/local
* Be sure to use the same compiler and options to compile your OpenSSL, perl,

and Net::SSLeay. Mixing and matching compilers is not supported.

Checking if your kit is complete...
Looks good
WARNING: /opt/local/bin/perl5.28 is loading libcrypto in an unsafe way
zsh: abort /opt/local/bin/perl5.28 Makefile.PL

Closes: #63415

[markmentovai (Mark Mentovai)]

Thanks. The dyld problem is also on file with Apple as ​FB9725981.

[ryandesign (Ryan Carsten Schmidt)]

There were a number of commits Wednesday to attempt to resolve this but the problem remains.

[laughingtiger]

I was having this problem however I managed to install p5.28-net-ssleay immediately after rebooting the machine by first cleaning p5.28-net-ssleay and then doing an individual install of p5.28-net-ssleay. The problem first showed itself when reinstalling MacPorts on the machine (Mac Mini 2018) which had not been rebooted since the upgrade to Monterey. Maybe I was just lucky but subsequent installs now seem to be progressing ok.

[ghjimmy (Jimmy Aitken)]

I had the same problem after upgrading to a Monetery full release. Following the migration guide, it failed at p5.28-net-ssleay I ran sudo port uninstall p5.28-extutils-makemaker; sudo port install p5.28-net-ssleay as mentioned above and and then re-run sudo ./restore_ports.tcl myports.txt to complete the migration.

Trying to just re-install p5.28-net-ssleay failed, as I needed to remove the other port first. Hopefully this helps some others skip the pain that I went through...

[breiter (Brian Reiter)]

Wow. Well done and good sleuthing markmentovai.

[breiter (Brian Reiter)]

So, if I understand this correctly:

If you try to dlopen a /path/to/libcrypto.dylib that doesn't exist on disk dlopen will not simply return ENOENT but will instead dlopen libcrypto.dylib from the shared cache -- if it exists. Any code that tries to find a different version of a library that Apple includes in the shared cache by probing a set of paths until there is no ENOENT will open the Apple shared dylib version instead of the one it was looking for unless the first path it probed was correct. What happened here is the build script tried to dlopen /opt/local/libcrypto.dylib and if it had gotten ENOENT would have correctly loaded /opt/local/lib/libcrypto.dylib. Instead dlopen /opt/local/libcrypto.dylib which is set up to abort() unless it is opened by Apple's /usr/bin/python2 (and maybe some other things) but print out a warning:

WARNING: Executing a script that is loading libcrypto in an unsafe way. This will fail in a future version of macOS. Set the LIBRESSL_REDIRECT_STUB_ABORT=1 in the environment to force this into an error.

/usr/bin/python3 just aborts. Presumably there is some cohort of important stuff that relies upon /usr/bin/python to load /usr/lib/libcrypto.dylib that Apple doesn't want to totally break, yet.

The path /usr/lib/libcrypto.dylib also doesn't exist.

$ ls /usr/lib/libcrypto.dylib
ls: cannot access '/usr/lib/libcrypto.dylib': No such file or directory

Whatever redirects /usr/lib/libcrypto.dylib to the dylib shared cache is actually stuuuuupid and is only matching on the file name not the full canonical path.

Is this true for any dylib? If you try to dlopen something that doesn't exist on disk but does exist in the shared cache, you just magically get the shared cache version (that seems bad)? Or a special case bug libcrypto.dylib (less bad)?

[markmentovai (Mark Mentovai)]

@ryandesign comment:32:

The relevant snippet from your log is:

:debug:configure system:  cd "/opt/bblocal/var/macports/build/_opt_bblocal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5-net-ssleay/p5.28-net-ssleay/work/Net-SSLeay-1.90" && /opt/bblocal/bin/perl5.28 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang"
:info:configure Do you want to run external tests?
:info:configure These tests *will* *fail* if you do not have network connectivity. [n] n
:info:configure *** Found LibreSSL-2.8.3 installed in /usr
:info:configure *** Be sure to use the same compiler and options to compile your OpenSSL, perl,
:info:configure     and Net::SSLeay. Mixing and matching compilers is not supported.
:info:configure Checking if your kit is complete...
:info:configure Looks good
:info:configure WARNING: /opt/bblocal/bin/perl5.28 is loading libcrypto in an unsafe way
:info:configure sh: line 1: 81247 Abort trap: 6           /opt/bblocal/bin/perl5.28 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang"
:info:configure Command failed:  cd "/opt/bblocal/var/macports/build/_opt_bblocal_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5-net-ssleay/p5.28-net-ssleay/work/Net-SSLeay-1.90" && /opt/bblocal/bin/perl5.28 Makefile.PL INSTALLDIRS=vendor CC="/usr/bin/clang" LD="/usr/bin/clang"
:info:configure Exit code: 134
:error:configure Failed to configure p5.28-net-ssleay: configure failure: command execution failed

That Makefile.PL found LibreSSL-2.8.3 installed in /usr means that it discovered /usr/bin/openssl (this is openssl version output).

Assuming you’re at ​95af71cb7ba4 or later and actually do have MacPorts OpenSSL installed, this happened because you don’t have /opt/local/bin/openssl (which Net::SSLeay looks for) and fell back to /usr/bin/openssl. And you don’t have /opt/local/bin/openssl because I can see from your build log that your MacPorts installation is /opt/bblocal. See ​Makefile.PL:300.

With an OpenSSL (actually LibreSSL) installation detected at /usr, even with ​911ba56d1268 in place to avoid the attempted load of /usr/libcrypto.dylib, you would have attempted to load /usr/lib/libcrypto.dylib by exact absolute path, and that is, of course the poisoned dylib that we’re trying to avoid. And it’s also a dylib that we don’t intend to link against or load at all, since we do have our own libcrypto from our own OpenSSL installation that we’d like to use. So even if this wasn’t a build break in the past, it seems that it may not have been doing what was intended for MacPorts installations in locations other than /opt/local until ​cbbf887681f2, and then ​66569d9c7a6d broke it again.

The right way to force Makefile.PL to find the intended OpenSSL installation is to set OPENSSL_PREFIX, but this was unfortunately removed in ​66569d9c7a6d. That part of the change should be reverted.

[mf2k (Frank Schima)]

Cc'ing the submitter of the commit mentioned above for possible comment.

[danielluke (Daniel J. Luke)]

OK, Makefile.PL searches a list of paths, so we need to set OPENSSL_PREFIX=$prefix - I've just pushed that change.

[markmentovai (Mark Mentovai)]

This is getting off into the weeds a little bit, but I can’t think of a better place to discuss.

@breiter comment:36:

If you try to dlopen a /path/to/libcrypto.dylib that doesn't exist on disk dlopen will not simply return ENOENT but will instead dlopen libcrypto.dylib from the shared cache -- if it exists. Any code that tries to find a different version of a library that Apple includes in the shared cache by probing a set of paths until there is no ENOENT will open the Apple shared dylib version instead of the one it was looking for unless the first path it probed was correct. What happened here is the build script tried to dlopen /opt/local/libcrypto.dylib and if it had gotten ENOENT would have correctly loaded /opt/local/lib/libcrypto.dylib. Instead dlopen /opt/local/libcrypto.dylib which is set up to abort() unless it is opened by Apple's /usr/bin/python2 (and maybe some other things) but print out a warning:

WARNING: Executing a script that is loading libcrypto in an unsafe way. This will fail in a future version of macOS. Set the LIBRESSL_REDIRECT_STUB_ABORT=1 in the environment to force this into an error.

/usr/bin/python3 just aborts. Presumably there is some cohort of important stuff that relies upon /usr/bin/python to load /usr/lib/libcrypto.dylib that Apple doesn't want to totally break, yet.

This is essentially correct. dlopen doesn’t promise to expose errno in any particular way, but dlopen, upon encountering ENOENT internally, should fail and return NULL (and dlerror would indicate the problem as “image not found” (macOS 11) or, now, “no such file”). Instead, we’re seeing this new fallback behavior in macOS 12 that causes it to search for the library based on the path’s leaf name. You can see the search path by inspecting what dlerror has to say when you try to dlopen a library that doesn’t exist and for which the fallback search fails (so, not libcrypto.dylib):

mark@sweet16 zsh% ~/t_dlopen /enoent/libenoent.dylib 
t_dlopen: dlopen: dlopen(/enoent/libenoent.dylib, 0x0005): tried: '/enoent/libenoent.dylib' (no such file), '/usr/local/lib/libenoent.dylib' (no such file), '/usr/lib/libenoent.dylib' (no such file)

You can also, perhaps more directly, set DYLD_PRINT_SEARCHING=1, which indicates that this is called “default fallback”:

mark@sweet16 zsh% DYLD_PRINT_SEARCHING=1 ~/t_dlopen /enoent/libenoent.dylib
dyld[59641]: find path "/usr/lib/libSystem.B.dylib"
dyld[59641]:   possible path(original path): "/usr/lib/libSystem.B.dylib"
dyld[59641]:   found: dylib-from-cache: (0x00AA) "/usr/lib/libSystem.B.dylib"
dyld[59641]: find path "/enoent/libenoent.dylib"
dyld[59641]:   possible path(original path): "/enoent/libenoent.dylib"
dyld[59641]:   possible path(default fallback): "/usr/local/lib/libenoent.dylib"
dyld[59641]:   possible path(default fallback): "/usr/lib/libenoent.dylib"
dyld[59641]:   not found: "/enoent/libenoent.dylib"
t_dlopen: dlopen: dlopen(/enoent/libenoent.dylib, 0x0005): tried: '/enoent/libenoent.dylib' (no such file), '/usr/local/lib/libenoent.dylib' (no such file), '/usr/lib/libenoent.dylib' (no such file)

The “soft” warning discussing LIBRESSL_REDIRECT_STUB_ABORT comes in when the main executable is something explicitly allow-listed by the poisoned libcrypto.dylib stub. The list is:

/usr/bin/perl
/usr/bin/python
/usr/bin/ruby
/usr/bin/tcl
/usr/bin/tk
/System/Library/Frameworks/Python.framework
/System/Library/Frameworks/Ruby.framework
/System/Library/Frameworks/Tcl.framework
/usr/local/bin/astris

If your main executable, as identified by NSGetExecutablePath, begins with any of those paths, then you get the warning message but no abort(), unless you set the environment variable as the message describes. This is a substring search, so you might assume that /usr/bin/python ought to catch both Apple-shipped python2 and python3. python2, however, actually runs out of /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7, and you can see how that comes into play in the allow-list. python3 is unbundled from the OS, and what you see at /usr/bin/python3 is actually a stub to delegate to python3 embedded within the active developer tools installation in accordance with xcode-select rules (so, respecting DEVELOPER_DIR, etc. This ultimately winds up at a path like /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Resources/Python.app/Contents/MacOS/Python which, as you can see, is not in the allow-list, so Apple’s libcrypto.dylib is poison even for that interpreter.

The shared cache issue is somewhat irrelevant here. Internally, dyld is attempting a fallback by searching /usr/local/lib and /usr/lib for the leaf name of the module you’re attempting to load. It just so happens that libcrypto.dylib can be serviced via the cache and not the filesystem. You can even “beat” the poisoned libcrypto.dylib in /usr/lib (virtually, via the shared cache) by sticking your own libcrypto.dylib in /usr/local/lib and have it do whatever you want:

mark@sweet16 zsh% rm -f /usr/local/lib/libcrypto.dylib
mark@sweet16 zsh% ./t_dlopen /opt/local/libcrypto.dylib
WARNING: /Users/mark/t_dlopen is loading libcrypto in an unsafe way
zsh: abort      ./t_dlopen /opt/local/libcrypto.dylib
mark@sweet16 zsh% clang -Wall -Werror -x c -dynamiclib -o /usr/local/lib/libcrypto.dylib - << __EOF__ 
#include <stdio.h>

__attribute__((constructor))
static void Initialize() {
  fprintf(stderr, "I may not be the module you intended.\n");
}
__EOF__
mark@sweet16 zsh% ./t_dlopen /opt/local/libcrypto.dylib
I may not be the module you intended.

The path /usr/lib/libcrypto.dylib also doesn't exist.

$ ls /usr/lib/libcrypto.dylib
ls: cannot access '/usr/lib/libcrypto.dylib': No such file or directory

This is normal. Since macOS 11, Apple no longer ships any dylibs in the filesystem for things that are contained within the dyld shared cache.

Is this true for any dylib? If you try to dlopen something that doesn't exist on disk but does exist in the shared cache, you just magically get the shared cache version (that seems bad)? Or a special case bug libcrypto.dylib (less bad)?

There’s no special-casing here. This is how dyld behaves now on macOS 12, although it reflects new additions to the search path and not strictly the shared cache per se—but libraries can certainly be provided by the shared cache, as in the libcrypto.dylib case. It’s contrary to the dlopen documentation and, in my opinion, it’s a bug.

[danielluke (Daniel J. Luke)]

macports-dev would be a good place to have this discussion about dyld behavior on macOS 12 (it would reach more maintainers who might care than just those who have stumbled across this particular port/problem).

[ryandesign (Ryan Carsten Schmidt)]

Replying to danielluke:

OK, Makefile.PL searches a list of paths, so we need to set OPENSSL_PREFIX=$prefix - I've just pushed that change.

Thanks, [f5c07023aec0af236d208f8610d6282fdf56bc49/macports-ports] + [d5bfc31fc7c51171189fc57ad1cee6a4b91bc6c2/macports-ports] fixed it.

[markblackman]

as a sidenote, I build my Perl from perlbrew, also install modules from cpanm (rather than macports), however, I do use the OpenSSL macport builds to provide OpenSSL. I was obliged to use the following approach (symlinks to the dylibs in the openssl11/lib directory) to succeed. I think Net::SSLeay should handle this case better.

sudo port install openssl11
sudo ln -s /opt/local/libexec/openssl11/lib/libcrypto.dylib /opt/local/libexec/openssl11
sudo ln -s /opt/local/libexec/openssl11/lib/libssl.dylib /opt/local/libexec/openssl11
export OPENSSL_PREFIX=/opt/local/libexec/openssl11
cpanm Net::SSLeay

[Schamschula (Marius Schamschula)]

This is a different issue. Since this ticket was closed the openssl PortGroup was introduced. p5-net-ssleay needs to be modified to use the PortGroup.

[danielluke (Daniel J. Luke)]

I don't see where the openssl PortGroup comes into play on this (and if it is needed, I think it's a really bad idea for us to have random different ways to specify dependencies for different ports and we should fix things so that they work without openssl having to be special/different from any other dependency) - @markblackman it would be great if you could open a new ticket with details (and attach a main.log from a failed build).