feat(build): Improve OpenSSL libcrypto discovery #5572
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.