We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
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
Currently, it seems like when one uses features like tokio-native-tls, there is no option to use the vendored feature of its dependency crates, i.e. tokio-native-tls, native-tls, tungstenite, in order to use a statically linked copy of OpenSSL instead of dynamically link to the OS' OpenSSL (https://docs.rs/openssl/0.10.56/openssl/#vendored).
tokio-native-tls
vendored
If the above assumption is true, can a feature similar to what's done in tokio-tungstenite be used to achieve this?
The text was updated successfully, but these errors were encountered:
Sure, do you want to provide a PR for that?
Sorry, something went wrong.
No branches or pull requests
Currently, it seems like when one uses features like
tokio-native-tls
, there is no option to use thevendored
feature of its dependency crates, i.e. tokio-native-tls, native-tls, tungstenite, in order to use a statically linked copy of OpenSSL instead of dynamically link to the OS' OpenSSL (https://docs.rs/openssl/0.10.56/openssl/#vendored).If the above assumption is true, can a feature similar to what's done in tokio-tungstenite be used to achieve this?
The text was updated successfully, but these errors were encountered: