feat(build): Improve OpenSSL libcrypto discovery#5572
Merged
maddeleine merged 3 commits intoaws:mainfrom Dec 9, 2025
Merged
Conversation
272776b to
932eb96
Compare
932eb96 to
a9ca898
Compare
dougch
approved these changes
Dec 4, 2025
| INTERFACE_LINK_LIBRARIES) | ||
| if (OpenSSL_LINK_LIBRARIES) | ||
| foreach (link_library ${OpenSSL_LINK_LIBRARIES}) | ||
| target_link_libraries(AWS::crypto INTERFACE ${link_library}) |
Contributor
There was a problem hiding this comment.
nit; curious to know (STATUS) what's getting linked...
| run: | | ||
| libcrypto_dir="$(pwd)/openssl-3.5.4/openssl-install" | ||
| cmake . -Bbuild \ | ||
| -DCMAKE_PREFIX_PATH="${libcrypto_dir}" \ |
Contributor
There was a problem hiding this comment.
This is slightly different than the build.sh output in the comments? That appears to be using the system installed libcrypto, where-as this is building it anew- did you have an example of this workflow running/failing on mainline (or did I miss it)?
Contributor
Author
There was a problem hiding this comment.
Yeah it's linked in the description: https://github.com/goatgoose/s2n-tls/actions/runs/18793539852/job/53629032545?pr=20
The test output pasted in the description is from testing this change with the ubuntu25 system libcrypto.
maddeleine
approved these changes
Dec 8, 2025
maddeleine
added a commit
to maddeleine/s2n
that referenced
this pull request
Dec 10, 2025
This reverts commit 13f8249.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release Summary:
Resolved issues:
resolves #5078
Description of changes:
Currently, s2n-tls has a two-step process for discovering a libcrypto to link to. First, we search for AWS-LC's crypto-config.cmake file in the user's provided search paths or somewhere on the system. Then, if AWS-LC's config isn't found, we search directly for
libcrypto.a/libcrypto.soartifacts using our Findcrypto.cmake module, invoked by find_package().In the case that AWS-LC's config isn't found, and we search directly for libcrypto artifacts, it's possible that the libcrypto that's discovered may have its own dependencies. For example, OpenSSL can be configured with a dependency on zlib. In this case, s2n-tls will fail to build, because we don't properly specify the libcrypto dependencies that must be linked to (see #5075 (comment)). The current solution to workaround this would be for the user to specify the linker arguments manually depending on how the libcrypto is configured, with something like this:
Manually specifying linker arguments when building s2n-tls is not a great experience. And it's been reported that manually specifying these flags may not always work (though I haven't been able to reproduce this yet): #5078 (comment).
This PR adds a new step to the s2n-tls libcrypto search to invoke the FindOpenSSL CMake module. This performs a more sophisticated search for OpenSSL by looking for CMake/pkgconfig files that declare the dependencies for the discovered libcrypto. These dependencies are then automatically added to the libcrypto target, avoiding the need to manually specify them.
Call-outs:
This change resulted in the 32bit cross compile test discovering the system's normal 64 bit libcrypto instead of the intended 32 bit libcrypto. I updated the test to give s2n-tls the path to the 32 bit libcrypto so it would find it. This indicates that the new search procedure won't be 100% backwards compatible. However, I believe the change is safe under the assumption that if your use case requires a specific libcrypto (such as the 32 bit libcrypto in the cross compile test), you should be pathing to that libcrypto specifically rather than assuming s2n-tls will discover it first in its search process.
Testing:
A new test was added which confirms that s2n-tls is now able to link to an OpenSSL installation with a dependency on zlib. This test fails on mainline s2n-tls.
I also confirmed that this change allows s2n-tls to build on a ubunu25 instance without manually providing any linker arguments:
Before change
After change
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.