Repository navigation
Conversation
When H5PL_ALLOW_EXTERNAL_SUPPORT is GIT or TGZ, the ZSTD plugin wrapper skips find_package() but still tests ZSTD_FOUND to decide whether to build zstd. A ZSTD_FOUND left in the cache by another subproject (pkg_search_module caches its results) made it skip the build and link a bare "zstd". Adding SZ3, whose CMake runs pkg_search_module(ZSTD libzstd), broke the ZSTD plugin on macOS with "ld: library 'zstd' not found". Clear ZSTD_FOUND in the external-build branch.
brtnfld
force-pushed
the
fix-stale-found-external
branch
from
October 6, 2026 22:46
a49fed6 to
ce06d1f
Compare
This branch has not been deployed
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.
Problem
With
H5PL_ALLOW_EXTERNAL_SUPPORT=GITorTGZ, the ZSTD plugin wrapper skipsfind_package()but still checksZSTD_FOUNDto decide whether to build zstd. If another subproject has already leftZSTD_FOUNDin the cache, the wrapper skips the build and links whateverZSTD_LIBRARIESholds.pkg_search_module()caches its results, so this can happen.This is what breaks the macOS jobs in #286: SZ3's CMake runs
pkg_search_module(ZSTD libzstd), which finds Homebrew's zstd, and the ZSTD plugin then fails:Fix
Clear
ZSTD_FOUNDin the external-build branch ofZSTD/CMakeLists.txt. Nothing changes whenH5PL_ALLOW_EXTERNAL_SUPPORT=NOorZSTD_USE_EXTERNALis off.This is a backstop. The leak itself is being fixed upstream in SZ3, which should not run
pkg_search_modulewhen it uses its bundled zstd. The other plugin wrappers use the same pattern, but nothing currently collides with them, so they are left unchanged.Testing
macOS arm64, an installed HDF5 2.x,
TGZ, with the cache seeded as pkg-config leaves it (-DZSTD_FOUND=1 -DZSTD_LIBRARIES=zstd):h5zstdfails to build (zstd.hnot found), because zstd was never built