This repository was archived by the owner on Aug 2, 2022. It is now read-only.
Repository navigation
fix pinned builds on fresh macOS install - #8143
Merged
Merged
Conversation
swatanabe-b1
approved these changes
Oct 29, 2019
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Change Description
When running
eosio_build.sh -Pon a fresh macOS 10.14.6 install it fails when trying to bootstrap Boost’s build system. This failure is new to 2.0+ and appears to be due to a significant change in boost’s build system in 1.71 compared to the previous 1.70 used in 1.8.x.A little background: on macOS, by default, C header files (like
stdlib.h) are not installed in to/usr/include. Instead, they are kept inside the development tool app bundle such as in/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk. “apple clang” from Xcode or command line tools (such as unpinned build would use) is smart enough to use these headers automatically based on your configuration (xcode-selectetc). “vanilla clang” (such as a pinned build would use) cannot figure this out on its own: you must pass either-isysrootwith the correct path or set the environment variableSDKROOTto the correct path.For reasons that are not entirely clear to me, the old build system in boost 1.70 (used in 1.8.x releases) is not using the pinned compiler. This means that in 1.8.x, Boost is built with apple clang which doesn’t require any of the shenanigans like isysroot/SDKROOT. It also means we’re building boost with a different compiler then nodeos for 1.8.x, quite troubling but probably not worth fixing at 1.8’s late lifecycle.
The new build system in boost 1.71 does use the pinned compiler as desired and expected. However, the vanilla clang compiler is unable to find any C header files and fails to bootstrap or build boost. This PR exposes
SDKROOTto vanilla clang when bootstrapping and building boost so that C header files can be found.cmake projects (such as when building LLVM or building EOSIO) do not require this workaround because cmake is smart enough to figure out the appropriate setting and pass it as
-isysrooton its own. So, there is no need to try and persistSDKROOTbeyond the time needed to build Boost.Consensus Changes
API Changes
Documentation Additions