Issues building oqsprovider statically

[marcbrevoort-cyberhive]

I have two oqsprovider builds created with the same build script on different systems.
On these two systems, liboqs.a is bit-identical.
OpenSSL is built from the same commit; libssl.a is bit-identical between the systems, nm on libcrypto.a reports

19268c19268
< 0000000000000230 r list_sep.0
---
> 000000000000024c r list_sep.0

The build of oqsprovider.a differs substantially between the two systems (despite the identical build scripts) with the main difference being in the object files generated from oqsprov.c / oqsprov_capabilities.c. What might impact the content of these files?

[baentsch]

Without further information on your build env (OS? OpenSSL version?), this is hard to tell. You surely already checked all #defines? One that gave headaches recently is "OSSL_CAPABILITY_TLS_SIGALG_NAME": This got introduced only in OpenSSL3.2.0-dev... Older OpenSSL versions will cause wildly different binaries to be created for this file.

[marcbrevoort-cyberhive]

I'm building this on its own, rather than using scripts/fullbuild.sh which also builds OQS.
So one thing I needed to do was to manually set all the sig/kem algo flags.

I also suspect there's a minor issue with oqsprov.c,

#ifdef OQS_PROVIDER_STATIC
#define OQS_PROVIDER_ENTRYPOINT_NAME oqs_provider_init
#else
#define OQS_PROVIDER_ENTRYPOINT_NAME OSSL_provider_init
#endif // ifdef OQS_PROVIDER_STATIC

as flag OQS_PROVIDER_STATIC is undocumented. Should this have been OQS_PROVIDER_BUILD_STATIC?
(Defining OQS_PROVIDER_STATIC results in the expected entry point name being defined, of course, so it's just a small workaround).

[baentsch]

So one thing I needed to do was to manually set all the sig/kem algo flags.

That surely needs to be correct to get identical binaries. But then again this should've been done by the cmake files, independent of the build shellscripts, no?

Should this have been OQS_PROVIDER_BUILD_STATIC?

Indeed, this looks fishy to me. Tagging @thb-sb for feedback.

[ghost]

Hi!

OQS_PROVIDER_BUILD_STATIC and OQS_PROVIDER_STATIC are both used but not in the same context.

OQS_PROVIDER_BUILD_STATIC is a oqs-provider CMake option to tell CMake to build the provider as a static library, this is why there is the BUILD word in it.
When set to ON (the default is OFF), CMake adds a new compiler definition OQS_PROVIDER_STATIC (-DOQS_PROVIDER_STATIC).

Using two different symbols may be useful to avoid confusion when -D is used with CMake, since -D is also used to tell the compiler about a definition.

[baentsch]

Thanks for the explanation. Good for me. So "OQS_PROVIDER_STATIC" is an internal C-language define created when using the CMakeLists.txt files.

Using two different symbols may be useful to avoid confusion

Alright -- but then again we're using the same symbols everywhere else (both for cmake options as well as C-language defines)...

In any case the problem can only occur if the CMakeLists.txt files have not been used -- is this the case @marcbrevoort-cyberhive ? Same question as above with the single algorithm defines...

[marcbrevoort-cyberhive]

The bit that I'm trying to troubleshoot is that somehow on my local build with my build script, I get

$ nm oqsprovider_output/lib/liboqsprovider.a |grep kyber768
00000000000030e0 t ecp_p256_kyber768_gen_init
0000000000000ca0 t ecp_p256_kyber768_new_key
0000000000003040 t ecp_p384_kyber768_gen_init
0000000000000be0 t ecp_p384_kyber768_new_key
0000000000003540 t ecx_x25519_kyber768_gen_init
0000000000000c60 t ecx_x25519_kyber768_new_key
00000000000034a0 t ecx_x448_kyber768_gen_init
0000000000000c20 t ecx_x448_kyber768_new_key
0000000000002460 t kyber768_gen_init
0000000000000ba0 t kyber768_new_key
0000000000001680 D oqs_ecp_p256_kyber768_keymgmt_functions
0000000000001a40 D oqs_ecp_p384_kyber768_keymgmt_functions
00000000000017c0 D oqs_ecx_x25519_kyber768_keymgmt_functions
0000000000001900 D oqs_ecx_x448_kyber768_keymgmt_functions
0000000000001b80 D oqs_kyber768_keymgmt_functions

whereas a build produced by the same script on the build box shows undefined symbols,

$ nm liboqsprovider.a |grep kyber768
                 U oqs_ecp_p256_kyber768_keymgmt_functions
                 U oqs_ecp_p384_kyber768_keymgmt_functions
                 U oqs_ecx_x25519_kyber768_keymgmt_functions
                 U oqs_ecx_x448_kyber768_keymgmt_functions
                 U oqs_kyber768_keymgmt_functions
00000000000030e0 t ecp_p256_kyber768_gen_init
0000000000000ca0 t ecp_p256_kyber768_new_key
0000000000003040 t ecp_p384_kyber768_gen_init
0000000000000be0 t ecp_p384_kyber768_new_key
0000000000003540 t ecx_x25519_kyber768_gen_init
0000000000000c60 t ecx_x25519_kyber768_new_key
00000000000034a0 t ecx_x448_kyber768_gen_init
0000000000000c20 t ecx_x448_kyber768_new_key
0000000000002460 t kyber768_gen_init
0000000000000ba0 t kyber768_new_key
0000000000001680 D oqs_ecp_p256_kyber768_keymgmt_functions
0000000000001a40 D oqs_ecp_p384_kyber768_keymgmt_functions
00000000000017c0 D oqs_ecx_x25519_kyber768_keymgmt_functions
0000000000001900 D oqs_ecx_x448_kyber768_keymgmt_functions
0000000000001b80 D oqs_kyber768_keymgmt_functions

As for the build script, it looks like this -

#!/usr/bin/env bash
export APP_ROOT=$(realpath $(dirname $0))
pushd $APP_ROOT/oqs-provider/
git checkout main
git reset --hard HEAD

export AR=/usr/bin/x86_64-linux-musl-ar
export CC=/usr/bin/x86_64-linux-musl-gcc
export CXX="$CC"
export AS="$CC"
export LD="$CC"

export CMAKE_C_COMPILER="$CC"
export CMAKE_ASM_COMPILER="$AS"

# version 3.2-dev
export OPENSSL_DIR="$APP_ROOT/openssl/"
liboqs_outdir="$APP_ROOT/liboqs_output"
outdir="$APP_ROOT/oqsprovider_output"
arch=x86_64-unknown-linux-musl
rm -rf build
mkdir build
mkdir -p $outdir
pushd build
CMAKE_C_FLAGS=-DOQS_ENABLE_KEM_frodokem_640_aes \
-DOQS_ENABLE_KEM_frodokem_640_shake \
-DOQS_ENABLE_KEM_frodokem_976_aes \
-DOQS_ENABLE_KEM_frodokem_976_shake \
-DOQS_ENABLE_KEM_frodokem_1344_aes \
-DOQS_ENABLE_KEM_frodokem_1344_shake \
-DOQS_ENABLE_KEM_kyber_512 \
-DOQS_ENABLE_KEM_kyber_768 \
-DOQS_ENABLE_KEM_kyber_1024 \
-DOQS_ENABLE_KEM_bike_l1 \
-DOQS_ENABLE_KEM_bike_l3 \
-DOQS_ENABLE_KEM_bike_l5 \
-DOQS_ENABLE_KEM_hqc_128 \
-DOQS_ENABLE_KEM_hqc_192 \
-DOQS_ENABLE_KEM_hqc_256 \
-DOSSL_CAPABILITY_TLS_SIGALG_NAME \
-DOQS_ENABLE_SIG_dilithium_2 \
-DOQS_ENABLE_SIG_dilithium_3 \
-DOQS_ENABLE_SIG_dilithium_5 \
-DOQS_ENABLE_SIG_dilithium_2_aes \
-DOQS_ENABLE_SIG_dilithium_3_aes \
-DOQS_ENABLE_SIG_dilithium_5_aes \
-DOQS_ENABLE_SIG_falcon_512 \
-DOQS_ENABLE_SIG_falcon_1024 \
-DOQS_ENABLE_SIG_sphincs_sha2_128f_simple \
-DOQS_ENABLE_SIG_sphincs_sha2_128s_simple \
-DOQS_ENABLE_SIG_sphincs_sha2_192f_simple \
-DOQS_ENABLE_SIG_sphincs_shake_128f_simple \
-DOQS_PROVIDER_STATIC

cmake .. \
    -G Ninja \
    -DOQS_PROVIDER_BUILD_STATIC=ON \
    -DCMAKE_C_FLAGS="$CMAKE_C_FLAGS" \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_PREFIX_PATH=${liboqs_outdir} \
    -DOPENSSL_ROOT_DIR=${OPENSSL_DIR}/ \
    -DOPENSSL_INCLUDE_DIR=${OPENSSL_DIR}/include \
    -DOPENSSL_CRYPTO_LIBRARY=${OPENSSL_DIR}/libcrypto.a \
    -DOPENSSL_SSL_LIBRARY=${OPENSSL_DIR}/libssl.a \
    -DOQS_ALGS_ENABLED=All \
    -Dliboqs_DIR=${liboqs_outdir} \
    -DLIBOQS_DIR=${liboqs_outdir} \
    --install-prefix=${outdir}

    ninja oqsprovider install

    # We will be linking the library into the client, and not using it is an openssl module per-se,
    # therefore we need to rename the library file to make that possible
    mv $outdir/lib/oqsprovider.a $outdir/lib/liboqsprovider.a

    popd

popd

Both are ubuntu systems but given the different output, I expect the differences must be due to some build environment issue, just can't figure out what might be having such an impact on the resulting .a file.

What was the headache with -DOSSL_CAPABILITY_TLS_SIGALG_NAME? Given a 3.2-dev build (openssl commit 79cdbe893da0c613db97356d05c0b088e885707f, specifically) , what would this be expected to be set to?

[ghost]

The bit that I'm trying to troubleshoot is that somehow on my local build with my build script, I get
0000000000001680 D oqs_ecp_p256_kyber768_keymgmt_functions

whereas a build produced by the same script on the build box shows undefined symbols,
U oqs_ecp_p256_kyber768_keymgmt_functions
0000000000001680 D oqs_ecp_p256_kyber768_keymgmt_functions

In both outputs I can see that oqs_ecp_p256_kyber768_keymgmt_functions is well defined as data initialized in the data section.
.a files are just archives that contain all the .o object files, so oqs_ecp_p256_kyber768_keymgmt_functions is likely to be undefined in all .o files but one: oqs_kmgmt.c.o, where oqs_ecp_p256_kyber768_keymgmt_functions is actually defined:

oqs-provider/oqsprov/oqs_kmgmt.c

Line 940 in b6da1e9

MAKE_KEM_ECP_KEYMGMT_FUNCTIONS(p256_kyber768, OQS_KEM_alg_kyber_768, 128)

$ llvm-nm oqsprovider.a

…

oqsprov.c.o:
                 U oqs_ecp_p256_kyber768_keymgmt_functions

…

oqs_kmgmt.c.o:
00000000000079d0 D oqs_ecp_p256_kyber768_keymgmt_functions

Can you try the following on your local build machine?:

$ ar x liboqsoprovider.a oqsprov.c.o
$ nm oqsprov.c.o|grep oqs_ecp_p256_kyber768_keymgmt_functions 

you should see that oqs_ecp_p256_kyber768_keymgmt_functions is undefined in oqsprov.c.o.

[marcbrevoort-cyberhive]

$ nm oqsprov.c.o |grep oqs_ecp_p256_kyber768_keymgmt_functions
                 U oqs_ecp_p256_kyber768_keymgmt_functions
$ nm oqs_kmgmt.c.o|grep oqs_ecp_p256_kyber768_keymgmt_functions
0000000000001680 D oqs_ecp_p256_kyber768_keymgmt_functions

Yes, I confirm this is the case.

[baentsch]

What was the headache with -DOSSL_CAPABILITY_TLS_SIGALG_NAME?

That it was not present when someone built to non-openssl-3.2.0-dev. Clearly not the problem here.

I am still puzzled by the many cmake parameters you're passing. For example, only OPENSSL_ROOT_DIR should be needed, not all the other OPENSSL_ vars. Same with all the "OQS_ENABLE_KEM_" vars. They should be set within the liboqs standard include ("oqsconfig.h"). Why are you setting them all? It looks like the liboqs includes are not suitably set up -- and then all kind of mayhem may occur. Have you tried setting "liboqs_DIR" as an environment variable? The "-Dliboqs_DIR" approach is surprising to me...

[marcbrevoort-cyberhive]

Thanks for the help so far. I'd build with the fullbuild script but I haven't had much luck getting it to produce a working static library, as I'm cross-compiling.

One thing I came across was the

export DOQS_ALGS_ENABLED="$OQS_ALGS_ENABLED"

line which I believe should read

export DOQS_ALGS_ENABLED="-DOQS_ALGS_ENABLED=$OQS_ALGS_ENABLED"

to work in the context of cmake -GNinja $DOQS_ALGS_ENABLED
but since "All" is the default that does me just fine.

What I'm currently having trouble with is setting algorithm kyber768, which results in a message from OpenSSL,
"group 'kyber768' cannot be set".

I have confirmed that the oqs_provider_init function is being called and I know the symbols are defined in the .a file.

I can tell that the oqsprovider registers signature algorithms with openssl; I can see that
as I've added a printf statement to this loop in oqsprov.c

    // insert all OIDs to the global objects list
    for (i=0; i<OQS_OID_CNT;i+=2) {
        printf("Registering NID for %s\n", oqs_oid_alg_list[i+1]);

While this oqs_oid_alg_list contains all configured signature algorithms, there aren't any KEMs in there. I've looked at the template that generates the oqs_oid_alg_list (oqs-provider/oqs-template/oqsprov/oqsprov.c/assign_sig_oids.fragment) and this only contains code for adding signatures to the oqs_oid_alg_list, so I assume that's as intended. I can't see the KEMS being registered with OpenSSL though, at least not in the provider init. Any pointers where this happens? I couldn't help noticing array oqsprovider_keymgmt is initialised with both signature algos and kems, but it's not used outside oqsprov.c (unless one's supposed to do something with the OSSL_DISPATCH table after calling oqs_provider_init?)

[baentsch]

which I believe should read
export DOQS_ALGS_ENABLED="-DOQS_ALGS_ENABLED=$OQS_ALGS_ENABLED"

Absolutely correct. Thanks for the catch! Do you want to do a PR to fix this?

What I'm currently having trouble with is setting algorithm kyber768, which results in a message from OpenSSL,
"group 'kyber768' cannot be set".

What's the output of openssl list -providers and openssl list -kem-algorithms respectively?

While this oqs_oid_alg_list contains all configured signature algorithms, there aren't any KEMs in there.

That's OK, KEMs don't have OIDs (yet -- until #194 is done).

unless one's supposed to do something with the OSSL_DISPATCH table

"one" meaning "OpenSSL core logic", not users.

[marcbrevoort-cyberhive]

What's the output of openssl list -providers and openssl list -kem-algorithms respectively?

Well, there's a bit of a rub there as I'm doing a static build of oqsprovider, which openssl won't pick up as a plugin.
With the dynamic build I did previously, I got it to list all relevant kems and signature algorithms, i.e.

$ openssl list -signature-algorithms
  { 1.2.840.113549.1.1.1, 2.5.8.1.1, RSA, rsaEncryption } @ default
  { 1.2.840.10040.4.1, 1.2.840.10040.4.3, 1.3.14.3.2.12, 1.3.14.3.2.13, 1.3.14.3.2.27, DSA, DSA-old, DSA-SHA, DSA-SHA1, DSA-SHA1-old, dsaEncryption, dsaEncryption-old, dsaWithSHA, dsaWithSHA1, dsaWithSHA1-old } @ default
  { 1.3.101.112, ED25519 } @ default
  { 1.3.101.113, ED448 } @ default
  { 1.2.156.10197.1.301, SM2 } @ default
  ECDSA @ default
  HMAC @ default
  SIPHASH @ default
  POLY1305 @ default
  CMAC @ default

vs.

$ openssl list -signature-algorithms -provider oqsprovider
dilithium2 @ oqsprovider
p256_dilithium2 @ oqsprovider
rsa3072_dilithium2 @ oqsprovider
...
sphincsshake128fsimple @ oqsprovider
p256_sphincsshake128fsimple @ oqsprovider
rsa3072_sphincsshake128fsimple @ oqsprovider

but of course this doesn't say much about the state of the static build.

[baentsch]

Ah, OK - static libs may behave differently.

What I'm currently having trouble with is setting algorithm kyber768, which results in a message from OpenSSL,
"group 'kyber768' cannot be set".

In that case, I'd suggest tracing/instrumenting this OpenSSL function: Is it called at all in case of a static provider? Maybe digging "upwards and downwards" from there could help.

[marcbrevoort-cyberhive]

in file ssl/t1_lib.c, function add_provider_groups is being called, but only for provider default. When loading oqsprovider, oqs_provider_init is being triggered, but add_provider_groups is never called for provider oqsprovider.

I have confirmed with a #warning preprocessor directive that kyber768 is definitely being compiled in.

nm reports that 0000000000001b80 D oqs_kyber768_keymgmt_functions is defined in oqs_kmgmt.c.o. It just never seems to be advertised to openssl that it's there. Sure enough, the function that prints "group 'kyber768' cannot be set". compares against the full list of algos that are there - all from the default provider.

In what ways might static libs behave differently? Obviously load time matters (for dynamic libraries typically during program startup) as well as load order.

Is there a specific order in which things need to be executed for them to work? Currently up to the failure I have

• openssl init
• set search path
• (for static builds) add_builtin oqsprovider with a function pointer to oqs_provider_init in the static library
• load config file
• load default provider
• load oqs provider (this triggers oqs_provider_init)
• build SSL connector and set cert, set ciphersuites, set groups to "kyber768" (this fails).

[baentsch]

add_provider_groups is never called for provider oqsprovider

Then that's the problem. The question thus changes to "what is required for static providers to be iterated over via OSSL_PROVIDER_do_all?" : https://github.com/openssl/openssl/blob/4d5cfb229be8a52cdf961d9b7c5f6c1c0fa3b4f7/ssl/t1_lib.c#L392C10-L392C30

Does your (static) app call OSSL_PROVIDER_add_builtin? ...load alone doesn't cut it for static providers as far as I remember from

oqs-provider/test/test_common.c

Lines 55 to 59 in b6da1e9

	void load_oqs_provider(OSSL_LIB_CTX *libctx, const char *modulename, const char *configfile) {
	(void)configfile;
	T(OSSL_PROVIDER_add_builtin(libctx, modulename, OQS_PROVIDER_ENTRYPOINT_NAME));
	T(OSSL_PROVIDER_load(libctx, "default"));
	}

[marcbrevoort-cyberhive]

Yes, that's correct, add_builtin is being invoked. It is after all what provides openssl with a function pointer to oqs_provider_init. Subsequently, on loading oqsprovider, we can see the code that's in oqs_provider_init is being invoked. As required, prior to loading oqsprovider, I load "default".
Is an explicit call to ssl_load_groups needed in oqs_provider_init? The openssl source only seems to call ssl_load_groups in ssl/ssl_lib.c, in SSL_CTX *SSL_CTX_new_ex. This would imply ctx would have to be created after calling add_builtin, but then default and oqsprovider would necessarily not share their context with add_builtin.

[baentsch]

Is an explicit call to ssl_load_groups needed in oqs_provider_init?

No, that should not be necessary -- it works (ssl_load_groups operates correctly) when "dynamically" loaded after all. There must be something else.

When checking the tests of static builds I noticed
a) an apparent error in CI: Looking at this log for example, I don't see that "-DOQS_PROVIDER_BUILD_STATIC=ON" is set: Would you know what's happening here, @thb-sb ?
b) that "oqs_groups" tests apparently fail (silently) in just the same way: OSSL_PROVIDER_do_all fails to find "oqsprovider" and thus iterates "successfully" over nothing :-( My bad to not have noticed this before.

I think we need to debug into OSSL_PROVIDER_do_all to get to the bottom of this (as also ssl_load_groups depends on this function).

[marcbrevoort-cyberhive]

for example, I don't see that "-DOQS_PROVIDER_BUILD_STATIC=ON" is set

Don't know if these are built with the regular fullbuild.sh script, but locally I did also add static build flags to that previously -

@@ -37,6 +37,11 @@ else
    export DOQS_ALGS_ENABLED="-DOQS_ALGS_ENABLED=$OQS_ALGS_ENABLED"
 fi

+if [ "$OQS_PROVIDER_BUILD_STATIC" = "" ]; then
+   export DOQS_PROVIDER_BUILD_STATIC=""
+else
+   export DOQS_PROVIDER_BUILD_STATIC="-DOQS_PROVIDER_BUILD_STATIC=$OQS_PROVIDER_BUILD_STATIC"
+fi
 if [ -z "$OPENSSL_INSTALL" ]; then
  openssl version | grep "OpenSSL 3" > /dev/null 2>&1
  #if [ \($? -ne 0 \) -o \( ! -z "$OPENSSL_BRANCH" \) ]; then
@@ -123,9 +128,9 @@ if [ ! -f "_build/lib/oqsprovider.$SHLIBEXT" ]; then
    BUILD_TYPE=""
    # for omitting public key in private keys add -DNOPUBKEY_IN_PRIVKEY=ON
    if [ -z "$OPENSSL_INSTALL" ]; then
-       cmake -DOPENSSL_ROOT_DIR=$(pwd)/.local $BUILD_TYPE -S . -B _build && cmake --build _build
+       cmake $DOQS_ALGS_ENABLED $DOQS_PROVIDER_BUILD_STATIC -DOPENSSL_ROOT_DIR=$(pwd)/.local $BUILD_TYPE -S . -B _build && cmake --build _build
    else
-       cmake -DOPENSSL_ROOT_DIR=$OPENSSL_INSTALL $BUILD_TYPE -S . -B _build && cmake --build _build
+       cmake $DOQS_ALGS_ENABLED $DOQS_PROVIDER_BUILD_STATIC -DOPENSSL_ROOT_DIR=$OPENSSL_INSTALL $BUILD_TYPE -S . -B _build && cmake --build _build
    fi
    if [ $? -ne 0 ]; then
      echo "provider build failed. Exiting."

Happy to raise a PR for that one as well if useful.

[ghost]

a) an apparent error in CI: Looking at this log for example, I don't see that "-DOQS_PROVIDER_BUILD_STATIC=ON" is set: Would you know what's happening here, @thb-sb ?

Indeed, it was missing!
I've submitted a fix for that: #242

I also added a test for checking that oqsprovider.a exists when OQS_PROVIDER_BUILD_STATIC is set.

[marcbrevoort-cyberhive]

In openssl in provider_core.c, in ossl_provider_doall_activated I added printf statements to check for activation state of providers being looped over. Output:

provider do_all
Activating fallbacks
provs not null
ossl_provider_doall_activated iterating over provider oqsprovider
prov not activated
ossl_provider_doall_activated iterating over provider default
prov is activated

So now we know it's not adding groups because it thinks the oqsprovider is not activated.
However I'm loading a config file prior to loading the providers to ensure their activation status,

config_file: "/redacted/path/to/existing/pq.cnf"
OpenSSL config loaded successfully 1
adding builtin oqsprovider
Built-in OQS provider added
loading provider default
default provider loaded
loading provider oqsprovider
OQS provider loaded

The config file in question contains, as you would expect,

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[oqsprovider_sect]
activate = 1
ssl_conf = ssl_sect

[default_sect]
activate = 1

[baentsch]

Happy to raise a PR for that one as well if useful.

It surely would be. Ideally together with some documentation that explains how the code needs to be used/integrated differently when built that way. May be as simple as an echo statement ("Remember to use..." at the end of the build script if run with that flag) -- and/or extending https://github.com/open-quantum-safe/oqs-provider/blob/main/CONFIGURE.md#oqs_provider_build_static ...

But we surely also need to understand why this happens:

So now we know it's not adding groups because it thinks the oqsprovider is not activated.

Thanks for digging this far. Really weird. From reading this I would've expected that every provider explicitly loaded (via API) also gets activated. But then again, code like this makes me wonder whether it's getting deactivated....

[marcbrevoort-cyberhive]

provider_activate has been called
Set activated flag to 1
activation > 0
Set activated flag to 1
activation > 0
activate oqsprovider == true
provider_activate has been called
Set activated flag to 1
activation > 0
return actual oqsprovider

The "return actual" line is generated by a printf statement just before return,

    printf("return actual %s\n", name);
    return actual;

Looking into whether some destructors may be getting called prematurely now.

[marcbrevoort-cyberhive]

I think the oqsprovider was being deactivated due to going out of scope (easy to happen in Rust).

That's no longer happening but getting the "library has no ciphers" message now. I've confirmed both "default" and "oqsprovider" are being loaded:

loading provider default
Default provider loaded
loading provider oqsprovider
OQS provider loaded

In the openssl output from ssl/t1_lib.c, I had added

    if (num_deflt_grps == 0) {
        printf("num_deflt_grps==0\n");

and see this num_deflt_grps==0 being logged. While I also have a printf statement in discover_provider_groups, there's no evidence of discover_provider_groups being called (Update: possibly due to missing curly brackets in the if statements).

This still yielded the "library has no ciphers" message but this was resolved by going back to the CMAKE_C_FLAGS approach in my build script above.

With all that sorted, things work as expected.
I'll raise a pull request for the fullbuild.sh script but I think we can put this one to bed.

Thanks so much for your help, it's been instrumental in getting troubleshooting this thing.

[baentsch]

the oqsprovider was being deactivated due to going out of scope (easy to happen in Rust).

OK -- I have no experience in Rust -- so thanks for (having & using) that perspective.

I'll raise a pull request for the fullbuild.sh script

Looking forward to that. Feel free to add any further lessons to the BUILD_STATIC Markdown and add yourself to the Contributors section: You unearthed bugs and surely also helped me (and others reading this in the future) to understand "things static" some more.