[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
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
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
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
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
On Mar 7, 2024, at 10:31 PM, Matt Borland
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
On Mar 7, 2024, at 10:31 PM, Matt Borland
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
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
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