Build failures on macOS 12

[danielluke]

There's a dyld 'feature' on macOS 12 that is causing build failures. MacPorts is using this diff to work around it (by not attempting to load from $prefix):

macports/macports-ports@08e3e0b

There's some explanation of what's going on at that link as well.

[chrisnovakovic]

Thanks for letting us know about this, Daniel.

I'm not sure we'll be able to merge that patch in its current state (it looks like it'll have a negative impact on non-macOS platforms), but we should be able to make sure specifically that $prefix isn't checked on macOS.

[danielluke]

Sure - a more complete explanation is here: http://openradar.appspot.com/FB9725981

For Darwin, a strategy of checking for existence of libcrypto.dylib / libssl.dylib before linking would probably work well - for MacPorts we know we want to link with the libraries in Macports' $prefix/lib directory, so that patch + setting OPENSSL_PREFIX works without being too invasive.

If you have a way you'd like it to work, and it would be helpful, I can open a PR.

[jjn1056]

For what it's worth, I was killing hours trying to get this installed after upgrading to the newest MacOS and this tiny patch fixed it for me. Maybe if we are nervous about the patch we could limit it to only MacOS12? In any case it would be great to have this fixed. Would it help if I submitted a patch on the README.mac for 'people coping with macOS 12 and how to get this installed?

[h-vn]

Edit: use DEFINE instead of overriding CCFLAGS.

Here's some more information about the linking problems. On macOS 12.0.1 / Intel I have:

• Perl 5.34.0 installed with perlbrew
• OpenSSL 3.0.0 compiled from source and installed to $HOME/opt/openssl-3.0.0
• Net::SSLeay 1.91_01 downloaded from CPAN and unpacked under $HOME/src/Net-SSLeay-1.91_01

Attempting to create a Makefile for Net-SSLeay with OPENSSL_PREFIX=$HOME/opt/openssl-3.0.0 perl Makefile.PL fails with WARNING: .../perl is loading libcrypto in an unsafe way, the same problem the previous comments describe in more detail.

After the following change to Makefile.PL the failure goes away. Further testing shows that the failure is triggered when the prospective library directory exists but does not contain the desired library file. That is, $prefix/lib64 does not trigger the failure because the directory pointed by OPENSSL_PREFIX does not contain lib64 subdirectory.

205c205
<     for ($prefix, "$prefix/lib64", "$prefix/lib", "$prefix/out32dll") {
---
>     for ("$prefix/lib64", "$prefix/lib", "$prefix/out32dll", $prefix) {

With the above change a Makefile is created and the module compiles cleanly with the following:
make DEFINE='-Wno-deprecated-declarations -Wno-compound-token-split-by-macro'

The first flag is needed because deprecated functions are used intentionally. The second flag is for a warning that is triggered by clang 12 and is addressed by these commits, I think: Perl/perl5@415da10787d8fa51 and Perl/perl5@7169efc77525df70

However, it seems that even the latest Perl 5.35.6 still requires the second flag.

[h-vn]

Reordering in comment #329 (comment) above broke build with recent Strawberry Perls. Looks like the order needs to be kept as it is for Srawberry. Next step is to consider making darwin a special case.

[h-vn]

To summarise: the fix is now to use different directory order with darwin. The first attempt was to simply to reorder the directories, but this broke build with Strawberry Perl 5.26 and later. Now everything remains the same except for darwin.