[release] Boost 1.85.0 Release Candidate 1 is available.
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/> The SHA256 checksums are as follows: fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz 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 Mar 7, 2024, at 8:44 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/>
The SHA256 checksums are as follows:
fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz
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 built the release candidates on two machines (x86_64 and ARM), both running Mac OS 14.3.1 using Apple clang version 15.0.0 (clang-1500.3.9.4) I used C++ 03/11/14/17 and 20, and all of them except C++03 built successfully. Also, for each build, b2 emitted an error: [errno 2] failed to scan file '': No such file or directory I have spoken to Rene about the b2 error, and he says: 1. It’s harmless, 2. It will be fixed for the 1.85.0 release. — Marshall
I have successfully built the beta under clang-19, C++23, Ubuntu 22.04. Note that there are warnings in Boost.Asio and Boost.Wave regarding deprecated enum to arithmetic conversions. Regards, Ruben. On Thu, 7 Mar 2024 at 17:45, Marshall Clow via Boost <boost@lists.boost.org> wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/>
The SHA256 checksums are as follows:
fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mar 7, 2024, at 4:51 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Ruben Perez wrote:
I have successfully built the beta under clang-19, C++23, Ubuntu 22.04.
Note that there are warnings in Boost.Asio and Boost.Wave regarding deprecated enum to arithmetic conversions.
Aren't these errors in Clang 18 (and presumably 19)?
Peter — Are you thinking of https://github.com/boostorg/mpl/issues/69 — Marshall
Marshall Clow wrote:
On Mar 7, 2024, at 4:51 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Ruben Perez wrote:
I have successfully built the beta under clang-19, C++23, Ubuntu 22.04.
Note that there are warnings in Boost.Asio and Boost.Wave regarding deprecated enum to arithmetic conversions.
Aren't these errors in Clang 18 (and presumably 19)?
Peter —
Are you thinking of https://github.com/boostorg/mpl/issues/69
No, I was thinking of this part from the 18 release notes: "Implemented P2864R2 Remove Deprecated Arithmetic Conversion on Enumerations From C++26." https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2864r2.pdf (https://prereleases.llvm.org/18.1.0/rc3/tools/clang/docs/ReleaseNotes.html) but I now notice that this says C++26 and Ruben used C++23.
Aren't these errors in Clang 18 (and presumably 19)?
Peter —
Are you thinking of https://github.com/boostorg/mpl/issues/69
No, I was thinking of this part from the 18 release notes:
"Implemented P2864R2 Remove Deprecated Arithmetic Conversion on Enumerations From C++26."
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2864r2.pdf
(https://prereleases.llvm.org/18.1.0/rc3/tools/clang/docs/ReleaseNotes.html)
but I now notice that this says C++26 and Ruben used C++23.
Yes, these are the conversions I'm referring to. According to cppreference, these are deprecated in C++20 and 23, and removed in C++26. See https://en.cppreference.com/w/cpp/language/usual_arithmetic_conversions. I guess this is why we're getting just warnings.
On 3/7/24 19:44, Marshall Clow via Boost wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/>
The SHA256 checksums are as follows:
fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz
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 archive still contains directory "_" in libs. This issue appeared in 1.84 and was reported here: https://github.com/boostorg/release-tools/issues/57
On Thu, Mar 7, 2024 at 10:44 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:
Available at: < https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/>
The SHA256 checksums are as follows:
fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz
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
Mostly looks good on Windows/Visual Studio. I do see the same [errno 22] failed to scan file '': Invalid argument that others have been reporting. It would be very nice if this is fixed in the release. Also, for msvc-14.0 only, I see a bunch of noise around wave, but not any actual errors...just stuff indicating that the 2nd build still had something causing files needed to be re-copied. I believe this is related to the above "error" report. toolset arch compile Link Execute msvc-14.0 32 X X X msvc-14.0 64 X X X 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 Compile means that the b2 command completed without errors with the weird "error". 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. Tom
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
I have successfully built the libraries on M1 Mac running macOS Sonoma 14.3.1 with Clang 17.0.6 using cxxstd=11,14,17,20,23. On the same platform using homebrew gcc-13 13.2.0 I get build failures with boost.fiber and boost.coroutine. b2 has the following error: error: No best alternative for libs/context/build/asm_sources with <abi>aapcs <address-model>64 <architecture>arm <asynch-exceptions>off <binary-format>mach-o <boost.cobalt.executor>any_io_executor <boost.cobalt.pmr>std <context-impl>fcontext <coverage>off <cxxstd-dialect>iso <cxxstd>17 <debug-symbols>off <deduced-address-model>64 <deduced-architecture>arm <exception-handling>on <extern-c-nothrow>off <inlining>full <link>shared <optimization>speed <os>MACOSX <pch>on <preserve-test-targets>on <profiling>off <python-debugging>off <python>3.11 <relevant>abi <relevant>address-model <relevant>architecture <relevant>binary-format <relevant>toolset <rtti>on <runtime-debugging>off <runtime-link>shared <stdlib>native <strip>off <target-os>darwin <testing.execute>on <threadapi>pthread <threading>multi <toolset-gcc:version>13 <toolset>gcc <variant>release <vectorize>off <visibility>hidden <warnings-as-errors>off <warnings>on no match: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang no match: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc no match: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc no match: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang no match: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin no match: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc no match: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang no match: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc no match: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang no match: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin no match: <abi>aapcs <address-model>64 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc no match: <abi>sysv <address-model>64 <architecture>loongarch <binary-format>elf <threading>multi <toolset>gcc no match: <abi>o32 <address-model>32 <architecture>mips <binary-format>elf <threading>multi <toolset>clang no match: <abi>o32 <address-model>32 <architecture>mips <binary-format>elf <threading>multi <toolset>gcc no match: <abi>n64 <address-model>64 <architecture>mips <binary-format>elf <threading>multi <toolset>clang no match: <abi>n64 <address-model>64 <architecture>mips <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang no match: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang no match: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>gcc no match: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin no match: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang no match: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang no match: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang no match: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin no match: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang no match: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc no match: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi no match: <abi>sysv <address-model>64 <architecture>riscv <binary-format>elf <threading>multi <toolset>clang no match: <abi>sysv <address-model>64 <architecture>riscv <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>s390x <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>s390x <binary-format>elf <threading>multi <toolset>clang no match: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang no match: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel no match: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang no match: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>embarcadero no match: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>borland no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>gcc no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin no match: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel no match: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang no match: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win no match: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc no match: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel no match: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc no match: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>embarcadero no match: <abi>x32 <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang no match: <abi>x32 <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc no match: <abi>x32 <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel no match: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi no match: <abi>sysv <architecture>arm+x86 <binary-format>mach-o <threading>multi Boost.Fiber fails with: gcc.link.dll bin.v2/libs/fiber/build/gcc-13/release/cxxstd-17-iso/threading-multi/visibility-hidden/libboost_fiber.dylib ld: warning: -single_module is obsolete ld: warning: ignoring duplicate libraries: '-lgcc' ld: Undefined symbols: _jump_fcontext, referenced from: __ZN5boost7context6detail11fiber_entryINS1_12fiber_recordINS0_5fiberENS_6fibers23stack_allocator_wrapperESt5_BindIFMNS5_18dispatcher_contextEFS4_OS4_EPS8_St12_PlaceholderILi1EEEEEEEEvNS1_10transfer_tE in context.o __ZN5boost6fibers19context_initializer10initializeENS_13intrusive_ptrINS0_4algo9algorithmEEEONS0_23stack_allocator_wrapperE.isra.0 in context.o __ZN5boost6fibers19context_initializer10initializeENS_13intrusive_ptrINS0_4algo9algorithmEEEONS0_23stack_allocator_wrapperE.isra.0 in context.o __ZN5boost6fibers5fiber4joinEv in fiber.o __ZN5boost6fibers5fiber6detachEv in fiber.o __ZN5boost6fibers9schedulerD1Ev in scheduler.o __ZN5boost6fibers9schedulerD1Ev in scheduler.o ... _make_fcontext, referenced from: __ZN5boost6fibers19context_initializer10initializeENS_13intrusive_ptrINS0_4algo9algorithmEEEONS0_23stack_allocator_wrapperE.isra.0 in context.o _ontop_fcontext, referenced from: __ZN5boost7context6detail11fiber_entryINS1_12fiber_recordINS0_5fiberENS_6fibers23stack_allocator_wrapperESt5_BindIFMNS5_18dispatcher_contextEFS4_OS4_EPS8_St12_PlaceholderILi1EEEEEEEEvNS1_10transfer_tE in context.o __ZN5boost7context6detail11fiber_entryINS1_12fiber_recordINS0_5fiberENS_6fibers23stack_allocator_wrapperESt5_BindIFMNS5_18dispatcher_contextEFS4_OS4_EPS8_St12_PlaceholderILi1EEEEEEEEvNS1_10transfer_tE in context.o __ZN5boost7context6detail11fiber_entryINS1_12fiber_recordINS0_5fiberENS_6fibers23stack_allocator_wrapperESt5_BindIFMNS5_18dispatcher_contextEFS4_OS4_EPS8_St12_PlaceholderILi1EEEEEEEEvNS1_10transfer_tE in context.o __ZN5boost7context6detail11fiber_ontopINS0_5fiberEZNS_6fibers7context15suspend_with_ccEvEUlOS3_E_EENS1_10transfer_tES8_ in context.o __ZN5boost7context6detail11fiber_ontopINS0_5fiberEZNS_6fibers7context6resumeEvEUlOS3_E_EENS1_10transfer_tES8_ in context.o __ZN5boost7context6detail11fiber_ontopINS0_5fiberEZNS_6fibers7context6resumeERSt11unique_lockINS4_6detail13spinlock_ttasEEEUlOS3_E_EENS1_10transfer_tESD_ in context.o __ZN5boost6fibers7contextD1Ev in context.o ... collect2: error: ld returned 1 exit status and Boost.Coroutine fails with: gcc.link.dll bin.v2/libs/coroutine/build/gcc-13/release/cxxstd-17-iso/threading-multi/visibility-hidden/libboost_coroutine.dylib ld: warning: -single_module is obsolete ld: warning: ignoring duplicate libraries: '-lgcc' ld: Undefined symbols: _jump_fcontext, referenced from: __ZN5boost10coroutines6detail17coroutine_context4jumpERS2_Pv in coroutine_context.o _make_fcontext, referenced from: __ZN5boost10coroutines6detail17coroutine_contextC2EPFvNS_7context6detail10transfer_tEERKNS1_12preallocatedE in coroutine_context.o __ZN5boost10coroutines6detail17coroutine_contextC1EPFvNS_7context6detail10transfer_tEERKNS1_12preallocatedE in coroutine_context.o collect2: error: ld returned 1 exit status Here is a gist with the complete build log: https://gist.github.com/mborland/781bf2740c30a2af93d1cdcbcb132337 Matt
On Mar 7, 2024, at 10:31 PM, Matt Borland <matt@mattborland.com> wrote:
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
I have successfully built the libraries on M1 Mac running macOS Sonoma 14.3.1 with Clang 17.0.6 using cxxstd=11,14,17,20,23.
On the same platform using homebrew gcc-13 13.2.0 I get build failures with boost.fiber and boost.coroutine.
b2 has the following error:
[snip] I have captured this as https://github.com/boostorg/coroutine/issues/63 — Marshall
fix is pushed 08.03.2024 17:24:52 Marshall Clow via Boost <boost@lists.boost.org>:
On Mar 7, 2024, at 10:31 PM, Matt Borland <matt@mattborland.com> wrote:
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
I have successfully built the libraries on M1 Mac running macOS Sonoma 14.3.1 with Clang 17.0.6 using cxxstd=11,14,17,20,23.
On the same platform using homebrew gcc-13 13.2.0 I get build failures with boost.fiber and boost.coroutine.
b2 has the following error:
[snip]
I have captured this as https://github.com/boostorg/coroutine/issues/63
— Marshall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 07.03.24 17:44, Marshall Clow via Boost wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/>
The SHA256 checksums are as follows:
fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz
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 can't get this release candidate to build at all. bootstrap.sh generates a non-working b2 executable. Trying to run b2 produces the following output: ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./b2) ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./b2) ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./b2) It's possible that there is something wonky with my build environment, but I can successfully build Boost 1.84 with the same environment. -- Rainer Deyke (rainerd@eldwood.com)
On Mar 11, 2024, at 3:40 AM, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
On 07.03.24 17:44, Marshall Clow via Boost wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/> The SHA256 checksums are as follows: fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz 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 can't get this release candidate to build at all. bootstrap.sh generates a non-working b2 executable. Trying to run b2 produces the following output: ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./b2) ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./b2) ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./b2)
It's possible that there is something wonky with my build environment, but I can successfully build Boost 1.84 with the same environment.
I just built the RC on Ubuntu using GCC 11.4. I didn’t have any problems like this. Can you share more information about your build environment? — Marshall
On 11.03.24 17:11, Marshall Clow via Boost wrote:
On Mar 11, 2024, at 3:40 AM, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
On 07.03.24 17:44, Marshall Clow via Boost wrote:
Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.85.0.beta1/source/> The SHA256 checksums are as follows: fa31215de3a4d2d010c0bc6e42cc63da76be82899f145ea6a6034b5bf3e6e297 boost_1_85_0_b1_rc1.zip 3b16d693acd4ee1745b0d9267555f7e34387527a02817f0c81bf8ec963b7c569 boost_1_85_0_b1_rc1.tar.bz2 20c7d2ccbbddeb56e618aa80960ea4dd38cbc4912b9a05fefef31c290519154e boost_1_85_0_b1_rc1.7z 7a28cd03e8e48b59a898900c953a9194b8f1efbb8c6149703b7faf08642c0cf7 boost_1_85_0_b1_rc1.tar.gz 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 can't get this release candidate to build at all. bootstrap.sh generates a non-working b2 executable. Trying to run b2 produces the following output: ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./b2) ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./b2) ./b2: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./b2)
It's possible that there is something wonky with my build environment, but I can successfully build Boost 1.84 with the same environment.
I just built the RC on Ubuntu using GCC 11.4. I didn’t have any problems like this.
Can you share more information about your build environment?
I am trying to produce portable binaries while using modern C++, so my policy is this: - Compile on a Docker image with an older OS installed (currently Ubuntu 16.04 LTS) so that I can link to an older libc. - Build my own compiler (currently gcc 13.2.0) instead of relying on the OS package manager. This means libraries are installed in /usr/local/lib64 instead of /usr/lib. - Statically link everything except libc, including libstdc++ (by setting CXXFLAGS=-static-libstdc++). - Deliberately don't point LD_LIBRARY_PATH to /usr/local/lib64, because these libraries won't exist on the target system and should only be statically linked. The problem is that while tools/build/src/engine/build.sh respects CXXFLAGS, bootstrap.sh deliberately clobbers CXXFLAGS from the environment, so b2 is built dynamically linked to a version of libstdc++ that it can't find at runtime. This explains why the b2 from the release candidate is broken. It doesn't explain the b2 from Boost 1.84 works, even though it also dynamically links to libstdc++. -- Rainer Deyke (rainerd@eldwood.com)
Rainer Deyke wrote:
I am trying to produce portable binaries while using modern C++, so my policy is this: - Compile on a Docker image with an older OS installed (currently Ubuntu 16.04 LTS) so that I can link to an older libc. - Build my own compiler (currently gcc 13.2.0) instead of relying on the OS package manager. This means libraries are installed in /usr/local/lib64 instead of /usr/lib. - Statically link everything except libc, including libstdc++ (by setting CXXFLAGS=-static-libstdc++). - Deliberately don't point LD_LIBRARY_PATH to /usr/local/lib64, because these libraries won't exist on the target system and should only be statically linked.
The problem is that while tools/build/src/engine/build.sh respects CXXFLAGS, bootstrap.sh deliberately clobbers CXXFLAGS from the environment, so b2 is built dynamically linked to a version of libstdc++ that it can't find at runtime.
You should use the --cxxflags option.
On 12.03.24 11:11, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
I am trying to produce portable binaries while using modern C++, so my policy is this: - Compile on a Docker image with an older OS installed (currently Ubuntu 16.04 LTS) so that I can link to an older libc. - Build my own compiler (currently gcc 13.2.0) instead of relying on the OS package manager. This means libraries are installed in /usr/local/lib64 instead of /usr/lib. - Statically link everything except libc, including libstdc++ (by setting CXXFLAGS=-static-libstdc++). - Deliberately don't point LD_LIBRARY_PATH to /usr/local/lib64, because these libraries won't exist on the target system and should only be statically linked.
The problem is that while tools/build/src/engine/build.sh respects CXXFLAGS, bootstrap.sh deliberately clobbers CXXFLAGS from the environment, so b2 is built dynamically linked to a version of libstdc++ that it can't find at runtime.
You should use the --cxxflags option.
That would work for tools/build/src/engine/build.sh, but bootstrap.sh neither understands that argument nor passes it along to build.sh. Anyway, now that I understand the problem, it's not hard to work around it by setting LD_LIBRARY_PATH just for while I'm building Boost. I managed to successfully build the subset of Boost that I am interested in, although I did get a warning about undefined behavior: In file included from libs/container/src/dlmalloc_ext_2_8_6.c:52, from libs/container/src/alloc_lib.c:24: In function ‘internal_multialloc_arrays’, inlined from ‘boost_cont_multialloc_arrays’ at libs/container/src/dlmalloc_ext_2_8_6.c:1112:13: libs/container/src/dlmalloc_ext_2_8_6.c:1085:41: warning: iteration 2305843009213693951 invokes undefined behavior [-Waggressive-loop-optimizations] 1085 | size = request2size(sizes[i]*element_size); | ^ libs/container/src/dlmalloc_2_8_6.c:2231:6: note: in definition of macro ‘request2size’ 2231 | (((req) < MIN_REQUEST)? MIN_CHUNK_SIZE : pad_request(req)) | ^~~ libs/container/src/dlmalloc_ext_2_8_6.c:1083:24: note: within this loop 1083 | for(++i; i != next_i; ++i) { | ~~^~~~~~~~~ -- Rainer Deyke (rainerd@eldwood.com)
participants (8)
-
Andrey Semashev -
Marshall Clow -
Matt Borland -
oliver.kowalke＠gmail.com -
Peter Dimov -
Rainer Deyke -
Ruben Perez -
Tom Kent