ci: stop three macOS arm64 dylibs from colliding in the *-libraries merge - #388
Merged
bernardladenthin merged 1 commit intoAug 13, 2026
Conversation
… merge All three macOS arm64 build jobs write net/ladenthin/llama/Mac/aarch64/libjllama.dylib (none passes -DOS_NAME/-DOS_ARCH, so CMakeLists auto-detects the same subdir), and all three uploaded under a name ending in `-libraries`. The package, publish-snapshot and publish-release jobs then download `pattern: "*-libraries"` with `merge-multiple: true` into one directory, so three different dylibs land on one path. The published dylib is consequently a hybrid: its ad-hoc linker signature no longer matches its own __TEXT pages, and macOS SIGKILLs any process that loads it. Verified on 5.0.6, 5.0.7-20260810.011118-18 and 5.0.7-20260811.201306-19 (66/4078 and 1141/4097 code pages fail their stored hashes); 5.0.7-20260801.013705-16 loads only because its foreign bytes happen to fall outside the signed range. macOS arm64 is the only <os>/<arch> with more than one artifact in the glob, which is why it is the only broken platform. Windows already avoids this by naming its MSVC variants outside the glob; this applies the same treatment to macOS: macos-15-libraries -> macos-15-no-metal (test-only) macos-14-libraries -> macos-14-metal (test-only) macos-15-metal-libraries -> macos-15-metal (shipped, selected explicitly) The variant that ships is now chosen by an explicit download step rather than by which artifact name happens to match a glob. macos-15-metal is the only build with both Metal and GGML_NATIVE=OFF, and it is what the current (corrupt) jars already report in their Mach-O header (minos 15.0 / sdk 15.5), so shipping it keeps the intended behaviour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bernardladenthin
changed the title
*-libraries…*-libraries merge
Owner
|
Ty @linking12 👍 |
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.
All three macOS arm64 build jobs write net/ladenthin/llama/Mac/aarch64/libjllama.dylib (none passes -DOS_NAME/-DOS_ARCH, so CMakeLists auto-detects the same subdir), and all three uploaded under a name ending in
-libraries. The package, publish-snapshot and publish-release jobs then downloadpattern: "*-libraries"withmerge-multiple: trueinto one directory, so three different dylibs land on one path.The published dylib is consequently a hybrid: its ad-hoc linker signature no longer matches its own __TEXT pages, and macOS SIGKILLs any process that loads it. Verified on 5.0.6, 5.0.7-20260810.011118-18 and 5.0.7-20260811.201306-19 (66/4078 and 1141/4097 code pages fail their stored hashes); 5.0.7-20260801.013705-16 loads only because its foreign bytes happen to fall outside the signed range.
macOS arm64 is the only / with more than one artifact in the glob, which is why it is the only broken platform. Windows already avoids this by naming its MSVC variants outside the glob; this applies the same treatment to macOS:
macos-15-libraries -> macos-15-no-metal (test-only)
macos-14-libraries -> macos-14-metal (test-only)
macos-15-metal-libraries -> macos-15-metal (shipped, selected explicitly)
The variant that ships is now chosen by an explicit download step rather than by which artifact name happens to match a glob. macos-15-metal is the only build with both Metal and GGML_NATIVE=OFF, and it is what the current (corrupt) jars already report in their Mach-O header (minos 15.0 / sdk 15.5), so shipping it keeps the intended behaviour.
Summary
Test plan
Related issues / PRs
Checklist
CONTRIBUTING.mdandCODE_OF_CONDUCT.mdSECURITY.md)