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.

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

[openssl:x64-windows] Provider legacy cannot be loaded #43314

Open
m-kuhn opened this issue Jan 16, 2025 · 1 comment
Open

[openssl:x64-windows] Provider legacy cannot be loaded #43314

m-kuhn opened this issue Jan 16, 2025 · 1 comment
Assignees
Labels
category:port-bug The issue is with a library, which is something the port should already support

Comments

@m-kuhn
Copy link
Contributor

m-kuhn commented Jan 16, 2025

Is your feature request related to a problem? Please describe.

The legacy provider is not found when built dynamically, most likely the search path is hardcoded to the original install dir.

This occurs for instance with py-requests-kerberos from https://github.com/open-vcpkg/python-registry is installed but also in
other scenarios, see #34949.

Typically, this happens if a cached openssl is used in a different install tree.

To workaround the issue, one can use a couple of approaches, either in the use application or with an env var, see openssl/openssl#18212.

Tested workaround: set(ENV{OPENSSL_MODULES} "${CURRENT_INSTALLED_DIR}/bin")

Proposed solution

openssl should be patched to be relocatable and support providers also when used from a different install tree.
Either in vcpkg, even better upstream.

Describe alternatives you've considered

#34949 discusses the alternative to build providers statically even if the port is built as dynamic, it remains unclear if this is a supported configuration by upstream, but would likely also fix the imminent issue.

Additional context

No response

@m-kuhn m-kuhn added the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Jan 16, 2025
@m-kuhn
Copy link
Contributor Author

m-kuhn commented Jan 18, 2025

Should actually be: category:port-bug

@MonicaLiu0311 MonicaLiu0311 added category:port-bug The issue is with a library, which is something the port should already support and removed category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist labels Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-bug The issue is with a library, which is something the port should already support
Projects
None yet
Development

No branches or pull requests

2 participants