build: use CMAKE_DL_LIBS instead of hardcoded dl#248
build: use CMAKE_DL_LIBS instead of hardcoded dl#248brtnfld merged 10 commits intoHDFGroup:masterfrom
Conversation
brtnfld
requested review from
ajelenak,
bmribler,
fortnern,
glennsong09,
jhendersonHDF,
lrknox and
mattjala
as code owners
| workflow_call: | ||
|
|
||
| env: | ||
| FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true |
There was a problem hiding this comment.
What is setting these in various actions used for here?
There was a problem hiding this comment.
to get rid of the Node.js 20 actions are deprecated warnings
brtnfld
force-pushed
the
fix/cmake-dl-libs-openbsd
branch
from
086b8aa to
6491042
Compare
Fixes link failures on OpenBSD (and other BSDs) where dlopen/dlsym are part of libc and there is no separate libdl. CMAKE_DL_LIBS resolves to the correct platform-specific library (dl on Linux, empty on BSD/macOS). Closes HDFGroup#243
Branch names like fix/foo contain a slash that zip interprets as a directory separator, causing "No such file or directory". Replace slashes with hyphens via tr.
actions/checkout@v4.1.7 runs on Node.js 20 which is deprecated on GitHub Actions runners (forced cutover June 2026). Update all references to v4.3.1. For third-party actions (dsaltares, cardinalby, jsdaniell, adriangl) that have not yet published Node.js 24 compatible releases, add FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true to each affected workflow so they opt in explicitly rather than hitting the forced cutover.
Checks weekly for new versions of all GitHub Actions used across workflows and opens grouped PRs to keep them current.
…ode 24 - actions/checkout: v4.3.1 -> v5.0.1 (Node 24 runtime) - actions/upload-artifact: v4 -> v7.0.1 (Node 24 runtime) - actions/download-artifact: v4.3.0 -> v8.0.1 (Node 24 runtime) Eliminates the remaining "forced to run on Node.js 24" warnings for first-party GitHub actions.
brtnfld
force-pushed
the
fix/cmake-dl-libs-openbsd
branch
from
6491042 to
53f3e63
Compare
jhendersonHDF
left a comment
jhendersonHDF
left a comment
There was a problem hiding this comment.
The MSVC vcpkg failure is known and needs investigating
vcpkg's ZLIBConfig.cmake throws a hard CMake error when COMPONENTS static is requested because ZLIB-static.cmake is absent in the x64-windows layout. Switching to OPTIONAL_COMPONENTS lets CMake fall through to the legacy find_package(ZLIB) fallback instead of aborting configuration.
vcpkg's ZLIBConfig.cmake unconditionally tries to include ZLIB-static.cmake when any component (required or optional) is passed, and that file does not exist in the x64-windows (shared) triplet. Dropping the component entirely avoids the hard CMake error while still finding ZLIB correctly in all configurations.
vcpkg's ZLIBConfig.cmake tries to include ZLIB-static.cmake when any component is requested, but that file is absent in the x64-windows (shared) triplet, causing a hard CMake error. Skip the static component on Windows only; non-Windows builds retain the original behavior.
vcpkg installs Blosc2Config.cmake (mixed case) but the legacy fallback was calling find_package(BLOSC2) which looks for BLOSC2Config.cmake. vcpkg's cmake wrapper treats the name case-sensitively, so it fails to find the package. Adding Blosc2 to NAMES in the primary find_package call ensures vcpkg's config file is found correctly.
| if (NOT H5_BLOSC2_HEADER) | ||
| if (NOT BLOSC2_USE_EXTERNAL) | ||
| find_package (BLOSC2 NAMES ${BLOSC2_PACKAGE_NAME}${HDF_PACKAGE_EXT}) | ||
| find_package (BLOSC2 NAMES ${BLOSC2_PACKAGE_NAME}${HDF_PACKAGE_EXT} Blosc2) |
There was a problem hiding this comment.
I don't think this change is correct. It isn't looking for "BLOSC2", it's looking for what's specified by NAMES in BLOSC2_PACKAGE_NAME, which is already set to "Blosc2"
There was a problem hiding this comment.
All "HDF5 plugins testing" tests pass without this change. The previous 3 commits seem to be sufficient to fix the vcpkg ZLIB static problem for windows MSVC.
There was a problem hiding this comment.
What are you referring to? 0dfee3c fails without this fix.
There was a problem hiding this comment.
I saw Jordan's comment, checked the failures in actions at 1:20 pm and 1:59 pm May 6, that were resolved in the 2:15 run. I pulled the branch into my fork, removed the Blosc 2 added to line 129, and ran the HDF5 plugins testing workflow. Those tests still passed for me.
BLOSC2_PACKAGE_NAME is unconditionally set to "Blosc2" by config/CacheURLs.cmake, so adding "Blosc2" to NAMES is a no-op. The earlier CI failure was likely transient.
|
It appears the failure was due to vcpkg failing to download blosc2 in the commit that failed. However, I don't know why that didn't fail that particular step and should probably be looked into. |
4 participants
Fixes link failures on OpenBSD (and other BSDs) where dlopen/dlsym are part of libc and there is no separate libdl. CMAKE_DL_LIBS resolves to the correct platform-specific library (dl on Linux, empty on BSD/macOS).
Closes #243