setup-deps-standalone: probe compiler for static Boost, not cmake --find-package#389
Merged
Conversation
…ind-package The auto Boost-linking probe from #388 used `cmake --find-package ... -DMODE=EXIST -DBoost_USE_STATIC_LIBS=ON`, which is a false positive: that mode only checks whether Boost is locatable at all and ignores Boost_USE_STATIC_LIBS. On distros that ship only libboost_*.so (CentOS/RHEL), it reports "static found", the script selects static linking, and the build dies at ninja time with `libboost_context.a ... missing` -- the exact failure #388 meant to fix. Replace the probe with one that asks the compiler driver to resolve each static archive moxygen actually links (context, filesystem, program_options, regex) via `c++ -print-file-name`. That returns an absolute path only when the .a exists in the compiler's own search paths -- definitive, no hardcoded paths, no distro sniffing. Also always pass -DBoost_USE_STATIC_LIBS explicitly (ON or OFF) instead of omitting it for shared. A re-run of `setup` reuses the existing build dir; omitting would leave a stale Boost_USE_STATIC_LIBS=ON in CMakeCache.txt in force. Verified: clean build picks shared and links; a poisoned =ON cache is overridden to OFF and still builds. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
gmarzot
approved these changes
Jun 5, 2026
gmarzot
left a comment
Contributor
There was a problem hiding this comment.
@gmarzot reviewed 1 file and all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on akash-a-n, michalhosna, mondain, Oxyd, peterchave, suhasHere, and TimEvens).
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.
The auto Boost-linking probe from #388 used
cmake --find-package ... -DMODE=EXIST -DBoost_USE_STATIC_LIBS=ON, which is a false positive: that mode only checks whether Boost is locatable at all and ignores Boost_USE_STATIC_LIBS. On distros that ship only libboost_*.so (CentOS/RHEL), it reports "static found", the script selects static linking, and the build dies at ninja time withlibboost_context.a ... missing-- the exact failure #388 meant to fix.Replace the probe with one that asks the compiler driver to resolve each static archive moxygen actually links (context, filesystem, program_options, regex) via
c++ -print-file-name. That returns an absolute path only when the .a exists in the compiler's own search paths -- definitive, no hardcoded paths, no distro sniffing.Also always pass -DBoost_USE_STATIC_LIBS explicitly (ON or OFF) instead of omitting it for shared. A re-run of
setupreuses the existing build dir; omitting would leave a stale Boost_USE_STATIC_LIBS=ON in CMakeCache.txt in force.Verified: clean build picks shared and links; a poisoned =ON cache is overridden to OFF and still builds.
This change is