fix(build): make Jolt IPO follow ENABLE_LTO, disable LTO for macOS CI - #493
Merged
Conversation
Root cause of the linux-clang-Release / macos-{Debug,Release} linker
failures on PR #491 was NOT a stale CI cache — a fresh local build
reproduced it. Extracting any member of build/lib/libJolt.a showed
LLVM IR bitcode, not ELF. GNU ld / ld64 then rejects the archive with:
libJolt.a: error adding symbols: file format not recognized
clang++: error: linker command failed with exit code 1
Jolt's CMake wrapper was forcing `INTERPROCEDURAL_OPTIMIZATION=ON`
whenever CMAKE_BUILD_TYPE was Release/MinSizeRel/RelWithDebInfo,
regardless of the top-level `ENABLE_LTO` option. The linux-clang CI
passes `-DENABLE_LTO=OFF` expecting native objects everywhere, but
Jolt still produced bitcode — a classic ABI/format mismatch that only
the thin-LTO-aware lld or llvm-ar can resolve.
Fix:
- CMakeLists.txt: gate Jolt's IPO on `ENABLE_LTO AND <release config>`
so the engine and Jolt stay in the same object format.
- build.yml: add `-DENABLE_LTO=OFF` to the macOS job. The job already
unconditionally purges `lib*.a` as a workaround — removing the
underlying mismatch lets that step become a no-op.
Verified locally: after the fix, `ar x libJolt.a AABBTreeBuilder.cpp.o`
yields ELF relocatable instead of LLVM IR bitcode.
Contributor
Code Coverage (GCC + lcov)Per-Subsystem Coverage
Total: 50.4% (27700/54914 lines) |
Contributor
❌ CI Error ReportFailed jobs: clang-tidy, macos-Debug, macos-Release Build ErrorsOther errors (1)Updated: 2026-04-18T07:56:51Z — this comment is updated in-place, not duplicated. |
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.
Root cause of the linux-clang-Release / macos-{Debug,Release} linker failures on PR #491 was NOT a stale CI cache — a fresh local build reproduced it. Extracting any member of build/lib/libJolt.a showed LLVM IR bitcode, not ELF. GNU ld / ld64 then rejects the archive with:
Jolt's CMake wrapper was forcing
INTERPROCEDURAL_OPTIMIZATION=ONwhenever CMAKE_BUILD_TYPE was Release/MinSizeRel/RelWithDebInfo, regardless of the top-levelENABLE_LTOoption. The linux-clang CI passes-DENABLE_LTO=OFFexpecting native objects everywhere, but Jolt still produced bitcode — a classic ABI/format mismatch that only the thin-LTO-aware lld or llvm-ar can resolve.Fix:
ENABLE_LTO AND <release config>so the engine and Jolt stay in the same object format.-DENABLE_LTO=OFFto the macOS job. The job already unconditionally purgeslib*.aas a workaround — removing the underlying mismatch lets that step become a no-op.Verified locally: after the fix,
ar x libJolt.a AABBTreeBuilder.cpp.oyields ELF relocatable instead of LLVM IR bitcode.