Boost 1.83 → 1.9x migration - #131
Merged
Merged
Conversation
Boost 1.87 removed Asio's long-deprecated interface. io_service had been a typedef of io_context since 1.66, so most of the churn is cosmetic, but a handful of classes genuinely went away and the plugins used them: - io_service::work -> executor_work_guard + make_work_guard - member post()/dispatch() -> free boost::asio::post() - resolver::query/iterator -> resolver::results_type (a range) 1.90 also dropped deadline_timer from the <boost/asio.hpp> umbrella. It still exists, so the validator plugin includes it explicitly rather than migrating to steady_timer, which would change the timer's clock semantics. Boost is now found in CONFIG mode, and System is requested only when it ships a CMake config: it is header-only since 1.69 and 1.90 no longer installs boost_systemConfig.cmake, so naming it in COMPONENTS hard-fails there while 1.83 still wants it named. Verified by compiling all 194 translation units against Boost 1.90.0 with the real build flags. The two x86-only files in fc's vendored equihash still gate a full arm64 link; that is a pre-existing portability gap, unrelated to Boost.
Neither is Boost-related; both were found while compiling every translation unit to verify the Boost 1.87+ port. - snapshot: macOS has no fdatasync, so the post-write durability fsync failed to compile there. F_FULLFSYNC is Apple's documented equivalent and also flushes the drive's own write cache, which plain fsync on macOS does not. - test_block_log: assigned signed_block::witness, a field renamed to validator, so this utility had not compiled for some time. Same stale-name defect fixed for consensus_sim in b2eb37b.
…atch The Boost 1.87 websocketpp fixes previously existed only in a local working copy, so CI -- which checks out submodules recursively -- would have compiled unpatched sources. fc now points vendor/websocketpp at VIZ-Blockchain's fork and pins the patched commit.
Noble ships Boost 1.83. Building 1.90 in a separate rarely-rebuilt image keeps the Boost compile out of per-PR builds, so warm CI stays at today's 4-6 min. Verified locally: the image builds in ~7.5 min, installs 20 static Boost libs and BoostConfig.cmake, and the project configures inside it against 1.90.0.
The builder stages now start from vizblockchain/boost:1.90-noble and drop the twelve distro libboost-*-dev packages; the remaining apt packages stay because re-running apt for them is a fast no-op that keeps each Dockerfile readable on its own. Boost lives at /usr/local, hence -DBOOST_ROOT. With the Docker build proving 1.90, the 1.83 end of the supported range is what now needs coverage, so a distro-Boost job is added. It is label-gated on check-boost-range rather than run per-PR: it is a from-scratch build with no layer cache.
Records the measured answer to the question operators will ask: yes, moving between a 1.83 and a 1.90 build requires a replay, because the segment's named-object index is not readable across the two.
The Boost 1.9x work uses side-by-side configure trees (e.g. build-190) to probe a second Boost version without disturbing the primary build/ directory. Ignore them.
The Boost 1.9x migration commits in fc, appbase and chainbase live on the viz-cx forks because the VIZ-Blockchain submodule repos are not writable from this account. Repoint .gitmodules so the branch resolves its submodules on clone. NOTE: flip these URLs back to VIZ-Blockchain/* before merge, once the submodule branches land on the canonical repos.
chiliec
added a commit
that referenced
this pull request
Aug 4, 2026
Publishes vizblockchain/boost:1.90-noble via the CI secrets so PR #131 can pull it before this PR merges. Revert before merging to master.
This reverts commit 99cf972.
The base image is published as a tag on the existing vizblockchain/vizd repo (vizblockchain/vizd:boost-base-1.90-noble) rather than a dedicated vizblockchain/boost repo, which the CI Docker Hub account cannot create. Point the production/testnet/dev builders, the base-image workflow, and the operator docs at that tag.
chiliec
added
the
check-boost-range
Boost 1.91 is the newest release (1.92 is not out yet). Drop the compiled 'system' library from the from-source Boost build: 1.91 removed the stub and b2 now rejects it as an unknown --with-libraries name. Headers still install and the project already probes for the boost_system CMake config, so nothing downstream needs it.
On1x
approved these changes
Aug 5, 2026
On1x
left a comment
On1x
left a comment
Member
There was a problem hiding this comment.
Reviewed the Boost 1.83 -> 1.9x migration.
Source changes are mechanical Asio modernization with preserved semantics: io_service->io_context, member .post()->boost::asio::post(), io_service::work->executor_work_guard/make_work_guard, direct <boost/asio/deadline_timer.hpp> include in the validator, and a macOS F_FULLFSYNC guard (Linux path stays fdatasync). No consensus/runtime behavior change on the production Linux build; the test_block_log witness->validator rename is a debug util. CMake rework is sound (CONFIG mode after FindBoost removal in 3.30, header-only Boost.System probe, BOOST_ASIO_HAS_BOOST_DATE_TIME for 1.87+).
Verified: CI green on both the Boost 1.83 range-floor job and the 1.91 Docker build; base image live; submodule pins (fc ba50f02, appbase dac87ca, chainbase 2f3e3cf) match the branch heads (now fast-forwarded onto their masters). No HF14/PM consensus code here — pure toolchain. LGTM.
On1x
marked this pull request as ready for review
August 5, 2026 04:56
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.
Boost 1.83 → 1.9x migration
Migrates the node to build against Boost 1.91 while keeping 1.83 working, so operators can move off the pinned 1.83 toolchain.
vizdlinks and runs against Boost 1.91; the 1.83 leg is exercised in CI as a label-gated range-floor job. Both legs are green.What's here
feat(build): support Boost 1.87+ alongside 1.83— the core source/build changes; dual-version support, no hard break for 1.83.fix: two portability defects surfaced by a full-tree compile— real defects the 1.9x full-tree compile exposed.fix(build): bump fc— picks up the forked websocketpp carrying the Asio patch.check-boost-range) 1.83 range-floor job. Thepull_requesttrigger now includeslabeledso applying the label actually starts a run.docs(operators)— upgrade note.fix(build): bump chainbase— Boost version stamp (derived fromBOOST_LIB_VERSION, so it tracks the version automatically).chore(build): ignore build-*/— side-by-side probe trees.Boost 1.91 note
1.91 removed the compiled
systemstub (Boost.System has been header-only since 1.69), sob2now rejectssystemas a--with-librariesname. The from-source Boost build drops it; the headers still install and the tree already probes for theboost_systemCMake config rather than assuming it (CMakeLists.txt), so nothing downstream needs the compiled lib.Submodules
The
fc,appbaseandchainbasemigration commits live on their canonicalVIZ-Blockchain/*repos on branchfeat/boost-1.9x;.gitmodulespoints at those canonical URLs. (Earlier revisions temporarily routed them throughviz-cxforks for access reasons; that has been fully reconciled and the forks deleted.)Submodule heads:
ba50f02dac87ca2f3e3cfBase image
The production/testnet/dev builders do
FROM vizblockchain/vizd:boost-base-1.91-noble. The Boost 1.91 builder image is published as a tag on the existingvizblockchain/vizdrepo (see PR #132) rather than a dedicatedvizblockchain/boostrepo, because the CI Docker Hub account can push tags to existing repos but cannot create a new one. If a dedicatedvizblockchain/boostrepo is provisioned later, the tag reference can be flipped over.Scope / follow-ups
vizd(the CI image works) plus a real mainnet snapshot, neither available on the dev machine.