[release] Boost 1.92.0 Beta 1 Release Candidate 1 is available
Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/> The SHA256 checksums are as follows: 11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2 585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz 290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z 005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers
On Jul 10, 2026, at 12:23 AM, Ion Gaztañaga via Boost <boost@lists.boost.org> wrote:
Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/>
The SHA256 checksums are as follows:
11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2
585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz
290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z
005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1_rc1.zip
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I have successfully built the libraries on Mac OS 26.5.2 using Apple clang version 21.0.0 (clang-2100.1.1.101) for c++11/14/17/20/23/2C There were a lot of warnings, but the builds were successful. Logs available upon request. — Marshall
On Jul 10, 2026, at 6:32 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
I have successfully built the libraries on Mac OS 26.5.2 using Apple clang version 21.0.0 (clang-2100.1.1.101) for c++11/14/17/20/23/2C
There were a lot of warnings, but the builds were successful. Logs available upon request.
A majority of the warnings could be removed by fixing these two bugs: https://github.com/bfgroup/b2/issues/566 https://github.com/boostorg/function_types/issues/16 — Marshall
For Windows/Visual Studio, I'm not seeing any build errors, but I do see this in the configuration stage....is it meaningful? First is this message: - cxx14_return_type_deduction : yes [15] - cxx14_variable_templates : yes [15] - cxx14_type_traits : yes [15] - std_wstreambuf builds : yes [15] - long double support : yes [15] - std_wstreambuf : yes [15] error: No best alternative for /D:/RB/boost_1_92_0/libs/graph_parallel/build/boost_graph_parallel with <abi>ms <address-model>32 <architecture>x86 <asynch-exceptions>off <binary-format>pe <boost.beast.allow-deprecated>on <boost.beast.separate-compilation>on <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <context-impl>fcontext <coverage>off <debug-store>object <debug-symbols>off <embed-manifest-via>linker <embed-manifest>on <exception-handling>on <extern-c-nothrow>off <inlining>full <known-warnings>hide <link>static <midl-robust>yes <midl-stubless-proxy>yes <optimization>speed <os>NT <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.14 <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>windows <testing.execute>on <threadapi>win32 <threading>multi <toolset-msvc:version>14.5 <toolset>msvc <variant>release <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on <windows-api>desktop <x-deduced-platform>x86_32 matched: (empty) matched: (empty) - lzma : no [15] - zstd : no [15] - has_lzma_cputhreads builds : no [15] - cxx11_alignas : yes [15] Other than that, things look good: toolset arch compile Link Execute msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X msvc-14.5 32 X X X msvc-14.5 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. More detailed logs can be found here: https://gist.github.com/teeks99/78412f87f4df904e7737439dd4031dc9 Tom On Fri, Jul 10, 2026 at 2:24 AM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/>
The SHA256 checksums are as follows:
11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2
585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz
290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z
005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1_rc1.zip
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
-- The Release managers _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/DF54PXL3...
El 10/07/2026 a las 9:23, Ion Gaztañaga via Boost escribió:
Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/>
The SHA256 checksums are as follows:
11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2
585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz
290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z
005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1_rc1.zip
I have successfully built the libraries on WSL Ubuntu 26.04 with gcc-11, gcc-12, gcc-13, gcc-14, gcc-15 and gcc-16. Best, Ion
On 10/07/2026 09:23, Ion Gaztañaga via Boost wrote:
Available at: <https://archives.boost.io/beta/1.92.0.beta1/source/>
The SHA256 checksums are as follows:
11f8f032a73cfd91899f170341578cabc040c4473e95a056cdc919c90778fa05 boost_1_92_0_b1_rc1.tar.bz2
585e0a028cc3f1f7711842b7cbfbb5faece2f243ef57ffe7fb846e9b61e2faa5 boost_1_92_0_b1_rc1.tar.gz
290472960719ccc487e2f91ebc952c86b6d0244a9a4ec36a943d8f7485b29b3b boost_1_92_0_b1_rc1.7z
005f4903695cce4382340ea57dd53bd1f0762927de28c9fa265f6ea2c7c1ad3f boost_1_92_0_b1_rc1.zip
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
-- The Release managers _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/DF54PXL3...
When trying to build it within a docker container it fails at my place. Attached my build script and Dockerfile so it can easily be reproduced. The error: + ./b2 variant=release cxxstd=23 stdlib=libc++ -j8 Performing configuration checks - default address-model : 64-bit [1] - default architecture : x86 [1] Building the Boost C++ Libraries. error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/config/checks' When running without docker everything goes fine and compiles cleanly. Is this maillinglist the correct place to report this issue? Regards, Matthijs Möhlmann
El 11/07/2026 a las 15:13, Matthijs Möhlmann via Boost escribió:
When trying to build it within a docker container it fails at my place.
Attached my build script and Dockerfile so it can easily be reproduced.
The error: + ./b2 variant=release cxxstd=23 stdlib=libc++ -j8 Performing configuration checks
- default address-model : 64-bit [1] - default architecture : x86 [1]
Building the Boost C++ Libraries.
error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/config/checks'
Does the error happen when making a simple /bootstrap.sh without arguments? Something like: ./bootstrap.sh ./b2 variant="release" cxxstd=23 stdlib=libc++ -j$(nproc) Best, Ion
- The default Clang on Debian 13 (Trixie) is Clang 19. What happens with Clang 19? - Is the operating system outside the container and inside, identical? (the same release of Debian 13?) What if you run the test on Ubuntu 22 and 24 containers? Of course it should work on Debian also, but this shows comparisons.
On 12/07/2026 00:25, Sam Darwin via Boost wrote:
- The default Clang on Debian 13 (Trixie) is Clang 19. What happens with Clang 19?
- Is the operating system outside the container and inside, identical? (the same release of Debian 13?) What if you run the test on Ubuntu 22 and 24 containers? Of course it should work on Debian also, but this shows comparisons. _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/GC62WUWE...
The result is the same with the default compiler (clang 19). The operating system and the container is identical (both Debian 13 (Trixie). Docker image: ubuntu:22.04 (Clang 14): same error. Docker image: ubuntu:24.04 (Clang 18): same error. Docker image: ubuntu:26.04 (Clang 21): same error. When looking at the error message: error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/config/checks' It says: `config/checks//cxx11_variadic_templates`. There is a double '//' there which indicates to me that some variable is replaced with an empty string? Regards, Matthijs
On 12/07/2026 12:26, Matthijs Möhlmann via Boost wrote:
On 12/07/2026 00:25, Sam Darwin via Boost wrote:
- The default Clang on Debian 13 (Trixie) is Clang 19. What happens with Clang 19?
- Is the operating system outside the container and inside, identical? (the same release of Debian 13?) What if you run the test on Ubuntu 22 and 24 containers? Of course it should work on Debian also, but this shows comparisons. _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/GC62WUWE...
The result is the same with the default compiler (clang 19).
The operating system and the container is identical (both Debian 13 (Trixie).
Docker image: ubuntu:22.04 (Clang 14): same error. Docker image: ubuntu:24.04 (Clang 18): same error. Docker image: ubuntu:26.04 (Clang 21): same error.
When looking at the error message: error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/config/checks'
It says: `config/checks//cxx11_variadic_templates`.
There is a double '//' there which indicates to me that some variable is replaced with an empty string?
No the double // is deliberate, can you take a peek inside your libs/config/checks/Jamfile.v2 and verify it has the line: obj cxx11_variadic_templates : test_case.cpp /boost/config//boost_config : <define>TEST_BOOST_NO_CXX11_VARIADIC_TEMPLATES ; ? Thanks, John.
On 12 Jul 2026 14:26, Matthijs Möhlmann via Boost wrote:
On 12/07/2026 00:25, Sam Darwin via Boost wrote:
- The default Clang on Debian 13 (Trixie) is Clang 19. What happens with Clang 19?
- Is the operating system outside the container and inside, identical? (the same release of Debian 13?) What if you run the test on Ubuntu 22 and 24 containers? Of course it should work on Debian also, but this shows comparisons.
The result is the same with the default compiler (clang 19).
The operating system and the container is identical (both Debian 13 (Trixie).
Docker image: ubuntu:22.04 (Clang 14): same error. Docker image: ubuntu:24.04 (Clang 18): same error. Docker image: ubuntu:26.04 (Clang 21): same error.
When looking at the error message: error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/ config/checks'
It says: `config/checks//cxx11_variadic_templates`.
There is a double '//' there which indicates to me that some variable is replaced with an empty string?
The double // separates the path and the target name, this is expected. Could you check the contents of /boost/boost_1_92_0/libs/config/checks/Jamfile.v2? It should contain the following line: obj cxx11_variadic_templates : test_case.cpp /boost/config//boost_config : <define>TEST_BOOST_NO_CXX11_VARIADIC_TEMPLATES ; That's the target that is reportedly missing. If it's there (as expected) then that seems like a b2 issue. One other thing to check is see if there is any permissions or disk storage issue. I know the build is supposed to be run under root within the container, but maybe there's some container-specific issue happening. Check that extracting the tar file succeeds and that the extracted tree is complete and readable (e.g. can you cat the Jamfile.v2 I mentioned in the build script?). Also, it would be nice to verify the checksum of the downloaded .tar.bz2 just in case. One other note is that your b2 command line should probably include toolset=clang (with no dashes). I'm not sure if b2 honors CC and CXX environment variables, but in any case, toolset=xyz is the proper way of selecting the compiler. This is why you set up user-config.jam after all. Though I don't expect it to be related to the missing target issue.
On 12 Jul 2026 15:41, Andrey Semashev wrote:
On 12 Jul 2026 14:26, Matthijs Möhlmann via Boost wrote:
On 12/07/2026 00:25, Sam Darwin via Boost wrote:
- The default Clang on Debian 13 (Trixie) is Clang 19. What happens with Clang 19?
- Is the operating system outside the container and inside, identical? (the same release of Debian 13?) What if you run the test on Ubuntu 22 and 24 containers? Of course it should work on Debian also, but this shows comparisons.
The result is the same with the default compiler (clang 19).
The operating system and the container is identical (both Debian 13 (Trixie).
Docker image: ubuntu:22.04 (Clang 14): same error. Docker image: ubuntu:24.04 (Clang 18): same error. Docker image: ubuntu:26.04 (Clang 21): same error.
When looking at the error message: error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/ config/checks'
It says: `config/checks//cxx11_variadic_templates`.
There is a double '//' there which indicates to me that some variable is replaced with an empty string?
The double // separates the path and the target name, this is expected. Could you check the contents of /boost/boost_1_92_0/libs/config/checks/Jamfile.v2? It should contain the following line:
obj cxx11_variadic_templates : test_case.cpp /boost/config//boost_config : <define>TEST_BOOST_NO_CXX11_VARIADIC_TEMPLATES ;
That's the target that is reportedly missing. If it's there (as expected) then that seems like a b2 issue.
One other thing to check is see if there is any permissions or disk storage issue. I know the build is supposed to be run under root within the container, but maybe there's some container-specific issue happening. Check that extracting the tar file succeeds and that the extracted tree is complete and readable (e.g. can you cat the Jamfile.v2 I mentioned in the build script?). Also, it would be nice to verify the checksum of the downloaded .tar.bz2 just in case.
One other note is that your b2 command line should probably include toolset=clang (with no dashes). I'm not sure if b2 honors CC and CXX environment variables, but in any case, toolset=xyz is the proper way of selecting the compiler. This is why you set up user-config.jam after all. Though I don't expect it to be related to the missing target issue.
One other thing to try is rename the build directory inside the container. E.g. instead of `mkdir /boost`, do `mkdir -p /build/boost` or something.
The build fails because Boost is unpacked into /boost/boost_1_92_0 and /boost is also Boost.Build's own top-level project id. The fix: Don't unpack/build Boost under a directory literally named /boost. In build-boost-llvm, change the working dir, e.g.: mkdir /opt/boost-src # instead of mkdir /boost cd /opt/boost-src and update the second-stage COPY in the Dockerfile accordingly (/boost/boost_1_92_0 → e.g. /opt/boost-src/boost_1_92_0). Any top-level path that isn't boost works (/opt, /usr/src, /build, /root/...). That single change makes the configuration checks resolve. """ "It's debatable whether b2 should be expected to catch this — rooted ids are meant to be a location-independent namespace, so a path colliding with one is arguably user error — but silently producing a doubled, non-existent path is a bad failure mode, and either a clearer diagnostic from b2 or a non-absolute reference from config.jam would prevent it."
On Sun, Jul 12, 2026 at 7:55 AM Sam Darwin via Boost <boost@lists.boost.org> wrote:
The build fails because Boost is unpacked into /boost/boost_1_92_0 and /boost is also Boost.Build's own top-level project id.
How did you verify that is the problem? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
How did you verify that is the problem?
claude opus, """ Reproduction (compiler-free) I isolated the mechanism with a tiny project. Identical in every way except the project id. I placed it at /home/sam/tmp/192/repro_bad, with a project id of /home (a path-prefix of that absolute location), versus /notaprefix for the control: Control (/notaprefix, not a prefix): ...found 1 target... — builds fine. Repro (/home, a prefix of the tree's absolute path): error: Unable to find file or target named error: '/home/sam/tmp/192/repro_bad/checks//foo' error: referred to from project at error: '.' error: could not resolve project reference '/home/sam/tmp/192/repro_bad/checks' That is byte-for-byte the same failure shape Matthijs reported, with /home playing the role of /boost. """
On 12/07/2026 14:55, Sam Darwin via Boost wrote:
The build fails because Boost is unpacked into /boost/boost_1_92_0 and /boost is also Boost.Build's own top-level project id.
The fix: Don't unpack/build Boost under a directory literally named /boost. In build-boost-llvm, change the working dir, e.g.: mkdir /opt/boost-src # instead of mkdir /boost cd /opt/boost-src and update the second-stage COPY in the Dockerfile accordingly (/boost/boost_1_92_0 → e.g. /opt/boost-src/boost_1_92_0). Any top-level path that isn't boost works (/opt, /usr/src, /build, /root/...). That single change makes the configuration checks resolve.
""" "It's debatable whether b2 should be expected to catch this — rooted ids are meant to be a location-independent namespace, so a path colliding with one is arguably user error — but silently producing a doubled, non-existent path is a bad failure mode, and either a clearer diagnostic from b2 or a non-absolute reference from config.jam would prevent it." _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/RMNLIAZJ...
Yes, this fixed my problem. After placing it in /build instead of /boost everything worked fine. Do you want me to report this agains boost build? (https://github.com/boostorg/build) ? Regards, Matthijs
On 11/07/2026 23:57, Ion Gaztañaga wrote:
El 11/07/2026 a las 15:13, Matthijs Möhlmann via Boost escribió:
When trying to build it within a docker container it fails at my place.
Attached my build script and Dockerfile so it can easily be reproduced.
The error: + ./b2 variant=release cxxstd=23 stdlib=libc++ -j8 Performing configuration checks
- default address-model : 64-bit [1] - default architecture : x86 [1]
Building the Boost C++ Libraries.
error: Unable to find file or target named error: '/boost/boost_1_92_0/libs/config/checks//cxx11_variadic_templates' error: referred to from project at error: '/boost/boost_1_92_0/libs/charconv/build' error: could not resolve project reference '/boost/boost_1_92_0/libs/config/checks'
Does the error happen when making a simple /bootstrap.sh without arguments? Something like:
./bootstrap.sh ./b2 variant="release" cxxstd=23 stdlib=libc++ -j$(nproc)
Best,
Ion
I am getting the same result without arguments to ./bootstrap.sh Regards, Matthijs
participants (8)
-
Andrey Semashev -
Ion Gaztañaga -
John Maddock -
Marshall Clow -
Matthijs Möhlmann -
René Ferdinand Rivera Morell -
Sam Darwin -
Tom Kent