Make available binaries

[baentsch]

Create ready-to-deploy binaries for

• Linux (.DEB)
• OSX , ideally via homebrew (resolving OSX support #46)
• Windows (.DLL) (resolving Windows support #47 and [Windows] OQS Provider Deployment #80)
• RedHat (.RPM)

Availability via GitHub artifact(s) or via other means? www.openquantumsafe.org? Input welcome (@dstebila ?)

Preferably for standardized algorithms (requires resolving #95 first)

In all cases, except for Windows, a separate install of liboqs shall be performed/used/triggered by the install package for oqsprovider.

In the case of Windows, it is considered better for usability (for the average Windows user) to only create a single DLL also including all required liboqs symbols and not requiring a separate liboqs install first. Suggestions welcome as to which install mechanism to use for the DLL (Ideas, @christianpaquin ?)

In the case of OSX, build and install shall be able to make use of the already existing homebrew formula for liboqs.

In the case of Linux distributions, build and install shall be able to make use of possibly already pre-installed liboqs packages.

[baentsch]

Since 0.5.1-dev, .deb, .dylib, .dll are always created via github actions and can be attached to releases as artifacts (first done with release 0.5.1). brew script available in https://github.com/open-quantum-safe/oqs-provider/blob/main/scripts/oqsprovider.rb.

RedHat .rpm not done as this is a commercial distro -- so asking @beldmit for feedback as to how best to do this "legally" --and or whether to do it at all, especially given open-quantum-safe/liboqs#1437. Accordingly relabelling this issue.

[catharsis71]

a .deb for ARM64 would be greatly appreciated
I was able to compile & make my own but it took a while because I normally don't keep all these build tools & dependencies installed

[baentsch]

a .deb for ARM64 would be greatly appreciated I was able to compile & make my own but it took a while because I normally don't keep all these build tools & dependencies installed

Good proposal. Unfortunately, a native ARM build in github CI seems out of the question given #248 (comment). Any other suggestions how to efficiently create and (CI-)test such binary welcome.

[ghost]

a .deb for ARM64 would be greatly appreciated I was able to compile & make my own but it took a while because I normally don't keep all these build tools & dependencies installed

Good proposal. Unfortunately, a native ARM build in github CI seems out of the question given #248 (comment). Any other suggestions how to efficiently create and (CI-)test such binary welcome.

We can try to cross-compile to aarch64. I'll give it a try later today.

Edit: PR: #253

[roelds]

Since this relates to Windows builds, I assume I don't need to make new issue.
fail.txt
I'm on fresh Windows 10 VM, latest Win SDK installed, with defaults & all requested libs found at:
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\um\x64
Using VC2022Pro since Community seemed to be missing libs. Trying to build: I get attached error in cmd admin output.
Where does the linker or makefile expect to find the libs? I have tried copying the libs from their default to almost every folder in C:\b & also by hardcoding the path in the makefile, which it interprets full path correctly, but still says it can't find it.
I was able to build liboqs ok, on this same PC, minutes before attempting building oqs-provider, so I'm confident this is not a pebkac issue. I'd like to do a native MSVC Windows build of this, since it's stated cross builds are not optimized on Windows, & my main use case is in Windows. If I can build this ok as requested, I can chime in with my preferences for deploying/packaging. Thanks!

[baentsch]

@roelds Thanks for the error log. It vaguely reminds me of a setup issue I also faced when doing #192 but I don't quite recall what it was (I'm absolutely not familiar with Windows and would be really glad to get a Windows experts' help). Have you checked the latest Windows CI build logs to see whether there is a glaring setup difference to your environment?

[roelds]

Thanks, I found out I was missing Ninja to build it, since I didn't need that for liboqs but I do for oqs-provider. Added ninja, then got syntax error during build, so I made new issue: #255

[baentsch]

Relabeling issue to "future work" until/when there'd be more contributors & maintainers in this project. Otherwise, support on binaries (security and other updates) cannot be guaranteed. Suggest withdrawing binaries from releases for the same reason and leave packaging to committed downstream teams.