Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

expose OQS_PERMIT_UNSUPPORTED_ARCHITECTURE, for example as cargo feature #202

Open
wucke13 opened this issue Apr 23, 2023 · 3 comments
Open

expose OQS_PERMIT_UNSUPPORTED_ARCHITECTURE, for example as cargo feature #202

wucke13 opened this issue Apr 23, 2023 · 3 comments

Comments

@wucke13
Copy link
Contributor

wucke13 commented Apr 23, 2023

I can't build my project for x86 with a musl libc due to open-quantum-safe/liboqs#1442 , and as I see there is no way to trigger the aforementioned CMake option using the rust wrapper, and due to #190 I can also not substitute the version of liboqs used externally 😞
wucke13 added a commit to rosenpass/liboqs-rust that referenced this issue Apr 23, 2023
@wucke13
fix open-quantum-safe#202
e514125 
This allows to set the `OQS_PERMIT_UNSUPOPORTED_ARCHITECTURE` CMake
option via an environment variable.
wucke13 added a commit to rosenpass/rosenpass that referenced this issue Apr 23, 2023
@wucke13
fix or exclude failing CI actions
da7be36 
Due to open-quantum-safe/liboqs-rust#202 it is not
yet possible to build the static Rosenpass version for `i686`. The CI actions
which fail for this reason have been excluded for now. Further on, some
the workflow names have been shortened for better overview.
wucke13 added a commit to rosenpass/rosenpass that referenced this issue Apr 23, 2023
@wucke13
fix or exclude failing CI actions
378fddb 
Due to open-quantum-safe/liboqs-rust#202 it is not
yet possible to build the static Rosenpass version for `i686`. The CI actions
which fail for this reason have been excluded for now. Further on, some
the workflow names have been shortened for better overview.
@thomwiggers
Copy link
Contributor

I'm not sure if it's not better to just wait for a fix for #190 to land upstream...

@wucke13
Copy link
Contributor Author

wucke13 commented Apr 24, 2023

I get the point, this is a bit about failure culture: does liboqs-rust assume that its use of CMake does not contain any errors, and that if there is an error the downstream lib user should have no grip on the matter, or does liboqs-rust enable the user on changing the behavior at the risk of allowing the user to compromise while doing so. I totally get why the second thing first thing sounds better, making a bullet-proof product that can't be used wrong is nice!

However, there is a tradeoff re usability. This and adjacent decisions make it more (one might even say: unnecessarily) complicated to use liboqs, which ultimately could hurt the goals of the oqs project. Please note, I'm no suggesting either way, I'm just pointing out observations (as we already considered replacing liboqs for various friction experienced with the build system).

Just for completeness, I made this to address open-quantum-safe/liboqs#1442, not to fix #190.

@thomwiggers
Copy link
Contributor

Euh right, that's the issue I meant to reference

github-merge-queue bot pushed a commit that referenced this issue Oct 18, 2023
feat(liboqs): allow setting OQS_PERMIT_UNSUPPORTED_ARCHITECTURE CMa…
8a0229a 
…ke option via environment variable (#203)

fix #202

This allows to set the `OQS_PERMIT_UNSUPOPORTED_ARCHITECTURE` CMake
option via an environment variable.
bacnh85 pushed a commit to bacnh85/liboqs-rust that referenced this issue Feb 15, 2024
@bacnh85
feat(liboqs): allow setting OQS_PERMIT_UNSUPPORTED_ARCHITECTURE CMa…
d1c15cf 
…ke option via environment variable (open-quantum-safe#203)

fix open-quantum-safe#202

This allows to set the `OQS_PERMIT_UNSUPOPORTED_ARCHITECTURE` CMake
option via an environment variable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thomwiggers @wucke13