we have several way of linking against openssl.
for example, we can link against openssl shipped with distro.

we do not rebuild openssl always (but it is one of alternatives)

in theory we can even link against libressl (but it's not a common case)

Yes, I understand. My changes are only to do with building in oqsprovider functionality, and they don't change anything about how OpenSSL is linked. On Windows, to the best of my knowledge, OpenSSL is linked statically, while on Linux, OpenSSL is dynamic. My changes don't affect how OpenSSL is linked at all, but only make sure that oqsprovider and liboqs are built in statically. For the LibreSSL edge case, I can disable oqsprovider and liboqs building, if that's not already accomplished by the most recent commit 1f9ce6f

meanwhile Fedora build failed

https://github.com/chipitsine/SoftEtherVPN/actions/runs/9782220953/job/27008057484

well, what am I afraid of is keeping an eye on updating git submodules (to keep them in sync with openssl).
@siddharth-narayan , do you have an appetite for that :) ?

I overlooked trigger definition in Fedora pipeline.

here's fix: #2025

Is the Fedora build working now, or do I need to push another commit to see it fail? For updating the git submodules, I don't think OpenSSL would break backwards compatibility that quickly, but if it's necessary, then of course I will come back and update them.

in Fedora openssl is built without provider support (but openssl >= 3)
it should be handled somehow.

I can prepare fix tomorrow.
if you have an appetite for that, I'd appreciate

Fedora pipeline was not enabled for pull requests, thus we missed that regression

After doing a bit of searching, I can't find any option to build OpenSSL without providers. It's doesn't seem to be in OpenSSL's ./Configure. Is the problem something related to engine support instead?

I did some digging, and I found the problem. I found your test commit to add

#ifndef OPENSSL_NO_ENGINE
#include <openssl/engine.h>
#endif

This seems to be completely correct, and should work properly. The only problem is that OPENSSL_NO_ENGINE isn't defined by the OpenSSL package on Fedora Rawhide. If you check the package, a very recent commit from two days ago removes engine*.h from the include directory without defining OPENSSL_NO_ENGINE. I think this is probably the issue.

I think the simplest solution is this:
For fixing the test, add openssl-devel-engine to the dependencies, and keep the #ifndef OPENSSL_NO_ENGINE guard for anyone else who builds with an OpenSSL that doesn't support engines.

I did some digging, and I found the problem. I found your test commit to add

#ifndef OPENSSL_NO_ENGINE
#include <openssl/engine.h>
#endif

This seems to be completely correct, and should work properly. The only problem is that OPENSSL_NO_ENGINE isn't defined by the OpenSSL package on Fedora Rawhide. If you check the package, a very recent commit from two days ago removes engine*.h from the include directory without defining OPENSSL_NO_ENGINE. I think this is probably the issue.

I think the simplest solution is this: For fixing the test, add openssl-devel-engine to the dependencies, and keep the #ifndef OPENSSL_NO_ENGINE guard for anyone else who builds with an OpenSSL that doesn't support engines.

we can mimic OPENSSL_NO_ENGINE in cmake,

I'll try installing openssl-devel-engine as well

The fix isn't very related to this pull request, but it might as well go here.

What did you mean by

we can mimic OPENSSL_NO_ENGINE in cmake,

The fix isn't very related to this pull request, but it might as well go here.

What did you mean by

we can mimic OPENSSL_NO_ENGINE in cmake,

I thought it was not a bug but intended behaviour.
in such case we can invoke check_symbol_exists(...) from CMake

in case it is a bug, let's stay with your approach by installing package on Fedora

I can accept Fedora pipeline fix immediately.

as for rest, it looks good, but I would have more look at it (well, I do not like an idea to add more submodules, but it seems to be the way those libs are served nowdays)

Ok, I can revert the commit here and make a separate pull request, which is probably best practice anyway.

About the git submodules, would CMake's FetchContent be an alternative? As far as I understand the library could be downloaded already compiled and then used that way. Would this work as an alternative?

since most people serve it as submodules, let's stick with submodules

Sorry, made a bad commit and accidentally pushed

if you still work on this PR, you can convert it to draft to avoid accidental merge

No, I'm not doing any active work, I was working on my master branch and accidentally pushed to this one.

I'll try to merge today

thank you for contribution!