t\local\39_pkcs12.t gives runtime error OPENSSL_Uplink(00007FFFBC46D000,08): no OPENSSL_Applink

[vrkosk]

I'm compiling Perl, openssl and Net::SSLeay using Visual Studio on Windows. I've tried all 36 combinations of: VS2015 and VS2017; Perl 5.30, 5.32, 5.34; openssl 1.0.2q, 1.1.1k; and Net::SSLeay 1.85. 1.88 and 1.90. In all cases, the 39_pkcs12.t test of Net::SSLeay fails with:

t\local\39_pkcs12.t .................... OPENSSL_Uplink(00007FFFBC46D000,08): no OPENSSL_Applink

Operating system is Windows Server 2019 (1809). This problem was reported many years ago in RT and updated as recently as 2020:

https://rt.cpan.org/Public/Bug/Display.html?id=101638

I couldn't find it in github issues (which is a bit shocking), so I'm opening a new issue.

When I apply the patch from the RT bug 101638 to Net::SSLeay 1.88 and recompile Net::SSLeay, the tests succeed. I haven't tried the patched version in a production system yet, because I don't fully understand what the patch does or whether it could cause other issues.

[jddurand]

An alternative seems to not depend on applink, using BIO. An example is here: confluentinc/librdkafka@6f33aee
Worked for me.

[h-vn]

Here are some more examples about discussions where avoiding applink is recommended as the correct solution:

• 05-test_rand.t failing for debug builds openssl/openssl#10086 (comment)
• https://www.mail-archive.com/openssl-dev@openssl.org/msg27638.html

Here's a snippet from the above openssl-dev list message for posterity. The OpenSSL project's mailing list archive seems not to reach that far:

Re: Win32 OPENSSL_USE_APPLINK usage
Andy Polyakov Tue, 20 Apr 2010 13:38:00 -0700

It should be noted that applink was introduced primarily in order to facilitate migration for legacy applications. New code should rather abstain from using above mentioned subset of OpenSSL API (whatever using FILE *) and simply avoid applink.