Tomáš Mráz

Does this patch work? ```patch diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index 1ab8c5fd70..ea2550859c 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -66,7 +66,7 @@ #undef NO_RECVMSG #define NO_RECVMSG # endif -# if defined(__ANDROID_API__) &&...

Are the make test errors exactly the same or different? If so, could you please paste the output here?

The test_lhash and test_symbol_presence failures look benign. However the test_bio_dgram failures are worse. Do you use the QUIC protocol implementation? If not, you can ignore that failure as well and...

Hmm... that's also a fairly strange failure. It seems like loading the legacy.so or something in the `.include` directive handling doesn't work correctly. Do you have `strace` on the system?

Try to run in the top level directory: ``` OPENSSL_MODULES=providers LD_LIBRARY_PATH=. strace -o logfile.txt test/conf_include_test -providers test/recipes/90-test_includes_data/includes-prov-dir.cnf ``` Assuming this fails, please attach the logfile.txt here.

Are there actually the libcrypto.so.3 and providers/legacy.so produced by the build?

This looks strange: `kload("./libcrypto.a(libcrypto64.so.3)", 16843648, ".") Err#2 ENOENT` and this `kload("providers/legacy.so", 16843392, ".") Err#2 ENOENT` as well.

In the first case the load does not make much sense to me at all. The second kload call looks fine however for some reason it doesn't see the providers/legacy.so...

Well, if you can build and test successfully with `no-dgram no-legacy` (excluding the test_symbol_presence and test_lhash as these failures do not seem to be a substantial issue) and you have...

It should definitely be possible to export/import the raw algorithm-specific keydata of an EVP_SKEY from a provider to another provider. Of course a provider could refuse the export operation if...