Make libhecdss self-contained: static zlib + static MSVC runtime#361
Merged
Conversation
The published natives weren't self-contained. On macOS the shipped dylib recorded @rpath/libz.1.dylib with the only LC_RPATH pointing at the build runner's path, so dyld couldn't resolve zlib off the build box -- an outright load failure. On Linux/macOS heclib_c linked *shared* zlib because deps/zlib/CMakeLists.txt aliased the static-named ZLIB::ZLIBSTATIC to madler/zlib's shared `zlib` target (the static one is `zlibstatic`). On Windows the DLL needed VCRUNTIME140.dll from the VC++ redistributable. Fixes: - Repoint ZLIB::ZLIBSTATIC at the real static `zlibstatic` target (PIC, with its includes) so the archive links into the shared libhecdss everywhere. - CMAKE_MSVC_RUNTIME_LIBRARY = MultiThreaded so the Windows DLL no longer depends on VCRUNTIME140.dll. Guards against regression: a `self_contained` ctest runs CMake's built-in file(GET_RUNTIME_DEPENDENCIES) on the built native and fails if it links anything outside the OS baseline. It needs only the built lib, so testing is now enabled unconditionally (no DSS test-data required).
nghiemv
force-pushed
the
fix/static-zlib-and-self-contained-check
branch
from
3e5f8aa to
30ece21
Compare
ktarbet
reviewed
Jun 16, 2026
ktarbet
left a comment
ktarbet
left a comment
Contributor
There was a problem hiding this comment.
Consider updating the Readme.md "Windows Dependencies" section.
It documented heclib.dll with Intel Fortran runtime DLLs (libifcore*, etc.) and debug-variant CRT -- but nothing in this tree builds heclib.dll, and the CMake project is C-only (no Fortran). The natives this repo actually ships are hecdss.dll and javaHeclib.dll, and after this change both are self-contained: static zlib + static MSVC runtime, so no VC++ redistributable and no Fortran runtime. Replace the stale list with the accurate one.
nghiemv
force-pushed
the
fix/static-zlib-and-self-contained-check
branch
from
4a5ef75 to
97c2241
Compare
|
Contributor
Author
|
Hi @ktarbet 😁 👋 Updated the README |
ktarbet
approved these changes
Jun 17, 2026
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
2 participants
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
The published natives aren't self-contained:
@rpath/libz.1.dylib, rpath = build-box path onlylibz.so.1VCRUNTIME140.dll(VC++ redistributable)The macOS case is an outright bug: the shipped
darwin-*dylib records@rpath/libz.1.dylibwith the onlyLC_RPATHpointing at the build runner's path, which exists nowhere else, sodyldcan't resolve zlib and the load fails. CI never caught it becausectestran in the same build tree where that rpath still resolves.Root cause:
deps/zlib/CMakeLists.txtaliased the static-namedZLIB::ZLIBSTATICto madler/zlib's sharedzlibtarget (the static one iszlibstatic).heclib_clinks that alias on every non-MSVC platform, so Linux/macOS linked shared zlib.Changes
ZLIB::ZLIBSTATICatzlibstatic(with its includes) and mark it position-independent so the archive links into the sharedlibhecdsson Linux/ELF.CMAKE_MSVC_RUNTIME_LIBRARYMultiThreaded, so the Windows DLL no longer needsVCRUNTIME140.dll.self_containedctest runs CMake's built-infile(GET_RUNTIME_DEPENDENCIES)on the built native and fails if it links anything outside the OS baseline. It needs only the built lib, so testing is now enabled unconditionally (no DSS test-data required).Scope
This is the bug fix + its regression test, split out for a fast review. The CI/Release/packaging rework and the consumer/JNI API tests follow in a stacked PR (
ci/release-build-package-and-api-tests).