[MacPorts] #63415: p5.28-net-ssleay failed to compile under Monterey (21A5304g)

[MacPorts]

#63415: p5.28-net-ssleay failed to compile under Monterey (21A5304g)
----------------------------+--------------------------
  Reporter:  ilTofa         |      Owner:  markmentovai
      Type:  defect         |     Status:  reopened
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.7.1
Resolution:                 |   Keywords:  monterey
      Port:  p5-net-ssleay  |
----------------------------+--------------------------

Comment (by breiter):

 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 local /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)?

-- 
Ticket URL: <https://trac.macports.org/ticket/63415#comment:36>
MacPorts <https://www.macports.org/>
Ports system for macOS