Repository navigation
Declare the SDKs' libcurl and OpenSSL as their link dependencies - #19
Merged
Merged
Conversation
When TileDB builds the AWS SDK or google-cloud-cpp itself, it links their static libraries through imported targets that did not say they need libcurl and OpenSSL. CMake puts a library on a link line once, after whatever declares a dependency on it, so with static OpenSSL libcrypto could come before google-cloud-cpp, and GNU ld then left its reference to BIO_f_base64 unresolved: executables linking tiledb_static failed to link, and shared libraries linked with the symbol undefined. Listing libcurl and OpenSSL after the SDKs in tiledb_static's link libraries did not place them after the SDKs. The imported targets now declare them as their link dependencies.
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.
When TileDB builds the AWS SDK or google-cloud-cpp itself, it links their static libraries through imported targets that didn't declare that they need libcurl and OpenSSL. CMake puts a library on a link line once, after whatever declares a dependency on it, so with static OpenSSL libcrypto could come before google-cloud-cpp's libraries. #17 listed libcurl and OpenSSL after the SDKs in tiledb_static's link libraries for that, but the order of that list doesn't decide where CMake puts them: in GenomicsDB's distributable build with GCC, OpenSSL lands right after azure-storage-lite, which also uses it, ahead of the SDKs, and GNU ld leaves google-cloud-cpp's reference to BIO_f_base64 unresolved: the test programs fail to link, and the shared library links with the symbol undefined, to fail when GCS code first calls it. With the SDKs already built, the AWS SDK's own CMake targets happen to pull OpenSSL in after them, which is why it shows only in clean builds.
The imported targets now declare libcurl and OpenSSL as their link dependencies, so CMake puts them after the SDKs.
Tested with GenomicsDB's distributable build, SDKs built from scratch, on Linux aarch64 with GCC 15.2 and clang 21 and on macOS arm64 with Apple clang 21: everything links and GenomicsDB's C++ tests pass. Without this change, GCC's link of GenomicsDB's library with -Wl,--no-undefined fails on BIO_f_base64.