[release] Boost 1.73.0 Release Candidate 1

newer
GSoC 2020 proposal review and GSoD

Marshall Clow

23 Apr 2020 23 Apr '20

1:53 p.m.

The first release candidates for the 1.73.0 release are now available at: https://dl.bintray.com/boostorg/release/1.73.0/source/ The SHA256 checksums are as follows: d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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

Show replies by date

Marshall Clow

23 Apr 23 Apr

2:17 p.m.

On Thu, Apr 23, 2020 at 6:53 AM Marshall Clow wrote:

...

The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

[ snip ]

...

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 Ubuntu 18.04 with the following compilers: * gcc 7.5.0: c++03/11/14/1z * clang-trunk: c++03/11/14/17/2a -- Marshall

Marshall Clow

9 p.m.

On Thu, Apr 23, 2020 at 6:53 AM Marshall Clow wrote:

...

The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

[snip]

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 this candidate with the following configurations: Mac OS 10.14.6 with Apple LLVM version 10.0.1 (clang-1001.0.46.4) Successful build with C++03/11/14/17/2a Mac OS 10.14.6 with with clang trunk (as of a couple weeks ago): Successful build with C++03/11/14/17/2a -- Marshall

Niall Douglas

27 Apr 27 Apr

11:03 a.m.

I assume it is too late for a segfault fix in Outcome for 1.73? Niall On 23/04/2020 22:00, Marshall Clow via Boost wrote:

...

On Thu, Apr 23, 2020 at 6:53 AM Marshall Clow wrote:

...
The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

[snip]

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 this candidate with the following configurations: Mac OS 10.14.6 with Apple LLVM version 10.0.1 (clang-1001.0.46.4) Successful build with C++03/11/14/17/2a

Mac OS 10.14.6 with with clang trunk (as of a couple weeks ago): Successful build with C++03/11/14/17/2a

-- Marshall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Marshall Clow

2:01 p.m.

On Mon, Apr 27, 2020 at 4:03 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

I assume it is too late for a segfault fix in Outcome for 1.73?

Tell me more, please. * How likely is someone to run into this? * Do you have a fix for it? * What's the likelihood of the fix causing other problems? -- Marshall

Niall Douglas

2:37 p.m.

On 27/04/2020 15:01, Marshall Clow wrote:

...

On Mon, Apr 27, 2020 at 4:03 AM Niall Douglas via Boost mailto:boost@lists.boost.org> wrote:

I assume it is too late for a segfault fix in Outcome for 1.73?

Tell me more, please.

* How likely is someone to run into this?

1. If in a Debug build. 2. If using Experimental.Outcome with a status_code_ptr.

...

* Do you have a fix for it?

https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653adc...

...

* What's the likelihood of the fix causing other problems?

Zero. Niall

Marshall Clow

3:47 p.m.

On Mon, Apr 27, 2020 at 7:37 AM Niall Douglas wrote:

...

On 27/04/2020 15:01, Marshall Clow wrote:

...
On Mon, Apr 27, 2020 at 4:03 AM Niall Douglas via Boost mailto:boost@lists.boost.org> wrote:

I assume it is too late for a segfault fix in Outcome for 1.73?

Tell me more, please.

* How likely is someone to run into this?

1. If in a Debug build.

2. If using Experimental.Outcome with a status_code_ptr.

[Letting people know what's up] After discussing this with Niall and the other release managers, we've determined: * This code was in 1.70/71/72. * It only happens with assertions enabled. and decided: * If we do an RC2, then we will include this. * This is not sufficient to justify an RC2 by itself. Unless something comes up, I'm planning on making the 1.73.0 release tonight/tomorrow morning -- Marshall

John Maddock

5:12 p.m.

...

Unless something comes up, I'm planning on making the 1.73.0 release tonight/tomorrow morning

Great! This may be one for a future release, but it's just been brought to my attention that some package managers have had issues with being unable to build 1.70 onwards... see https://bugzilla.redhat.com/show_bug.cgi?id=1558278, in particular 1.72 gives: + ./b2 -d+2 -q -j8 --with-mpi --with-graph_parallel --build-dir=openmpi-x86_64 variant=release threading=multi debug-symbols=on pch=off python=3.8 stage Performing configuration checks - default address-model : 64-bit - default architecture : x86 warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at /builddir/build/BUILD/boost_1_72_0/tools/build/src/user-config.jam:6 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:120 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:145 error: Name clash for '

libboost_serialization.so.1.72.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Does anyone know if this has been reported back to us and/or fixed? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Deniz Bahadir

5:42 p.m.

Am 27.04.20 um 19:12 schrieb John Maddock via Boost:

...

...
Unless something comes up, I'm planning on making the 1.73.0 release tonight/tomorrow morning

Great!

This may be one for a future release, but it's just been brought to my attention that some package managers have had issues with being unable to build 1.70 onwards... see https://bugzilla.redhat.com/show_bug.cgi?id=1558278, in particular 1.72 gives:

+ ./b2 -d+2 -q -j8 --with-mpi --with-graph_parallel --build-dir=openmpi-x86_64 variant=release threading=multi debug-symbols=on pch=off python=3.8 stage Performing configuration checks

- default address-model : 64-bit - default architecture : x86 warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at /builddir/build/BUILD/boost_1_72_0/tools/build/src/user-config.jam:6 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:120 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:145 error: Name clash for '
libboost_serialization.so.1.72.0'

error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

Does anyone know if this has been reported back to us and/or fixed?

Thanks, John.

Hi John, Isn't that (at least partially) the same error I reported for Boost.Regex (https://github.com/boostorg/regex/issues/89) and for which you provided a fix? Best regards, Deniz

Jonathan Wakely

8:43 p.m.

On Mon, 27 Apr 2020 at 18:51, Deniz Bahadir via Boost wrote:

...

Am 27.04.20 um 19:12 schrieb John Maddock via Boost:

...
...
Unless something comes up, I'm planning on making the 1.73.0 release tonight/tomorrow morning

Great!

This may be one for a future release, but it's just been brought to my attention that some package managers have had issues with being unable to build 1.70 onwards... see https://bugzilla.redhat.com/show_bug.cgi?id=1558278, in particular 1.72 gives:

+ ./b2 -d+2 -q -j8 --with-mpi --with-graph_parallel --build-dir=openmpi-x86_64 variant=release threading=multi debug-symbols=on pch=off python=3.8 stage Performing configuration checks

- default address-model : 64-bit - default architecture : x86 warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at /builddir/build/BUILD/boost_1_72_0/tools/build/src/user-config.jam:6 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:120 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:145 error: Name clash for

'
libboost_serialization.so.1.72.0'

...
error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

Does anyone know if this has been reported back to us and/or fixed?

Thanks, John.

Hi John,

Isn't that (at least partially) the same error I reported for Boost.Regex (https://github.com/boostorg/regex/issues/89) and for which you provided a fix?

No, it's unrelated. I emailed this list about the Fedora build problems a couple of weeks ago and Peter Dimov helped out. I am now able to build the Boost RPMs for Fedora, and will be updating Fedora rawhide (which will become Fedora 33) to Boost 1.73.0 in the near future. See https://fedoraproject.org/wiki/Changes/F33Boost173 if you're interested.

Jonathan Wakely

8:47 p.m.

On Mon, 27 Apr 2020 at 18:12, John Maddock via Boost wrote:

...

...
Unless something comes up, I'm planning on making the 1.73.0 release tonight/tomorrow morning

Great!

This may be one for a future release, but it's just been brought to my attention that some package managers have had issues with being unable to build 1.70 onwards... see https://bugzilla.redhat.com/show_bug.cgi?id=1558278, in particular 1.72 gives:

+ ./b2 -d+2 -q -j8 --with-mpi --with-graph_parallel --build-dir=openmpi-x86_64 variant=release threading=multi debug-symbols=on pch=off python=3.8 stage Performing configuration checks

- default address-model : 64-bit - default architecture : x86 warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at /builddir/build/BUILD/boost_1_72_0/tools/build/src/user-config.jam:6 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:120 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:145 error: Name clash for '
libboost_serialization.so.1.72.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

Does anyone know if this has been reported back to us and/or fixed?

It's caused by Fedora-specific patches, because we don't like some of the Boost policies (e.g. not linking liboost_python.so to libpythonX.Y.so and setting RPATHs in the libraries). Since it's due to our changes, I haven't reported it as a bug in Boost, but I did ask for help here (and asked if some of our changes could be optionally supported upstream, but that didn't seem popular). The problems have been resolved with Peter Dimov's expert guidance (thanks again, Peter!)

Glen Fernandes

28 Apr 28 Apr

12:08 a.m.

On Mon, Apr 27, 2020 at 11:47 AM Marshall Clow wrote:

...

After discussing this with Niall and the other release managers, we've determined: * This code was in 1.70/71/72. * It only happens with assertions enabled.

and decided: * If we do an RC2, then we will include this. * This is not sufficient to justify an RC2 by itself.

Unless something comes up, I'm planning on making the 1.73.0 release tonight/tomorrow morning

Niall, if you want we can provide a Boost.Outcome patch on the 1.73 release notes (in similar fashion to the Coroutine patch on https://www.boost.org/users/history/version_1_72_0.html under Known Issues) and on https://www.boost.org/patches/ . Glen

Niall Douglas

8:32 a.m.

On 28/04/2020 01:08, Glen Fernandes wrote

...

Niall, if you want we can provide a Boost.Outcome patch on the 1.73 release notes (in similar fashion to the Coroutine patch on https://www.boost.org/users/history/version_1_72_0.html under Known Issues) and on https://www.boost.org/patches/ .

Please find attached a diff against Boost 1.73 which was generated from bug fix commit https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653adc... Thanks for this, sorry for the bother. Niall

Andrey Semashev

11:29 a.m.

On 2020-04-28 11:32, Niall Douglas via Boost wrote:

...

On 28/04/2020 01:08, Glen Fernandes wrote

...
Niall, if you want we can provide a Boost.Outcome patch on the 1.73 release notes (in similar fashion to the Coroutine patch on https://www.boost.org/users/history/version_1_72_0.html under Known Issues) and on https://www.boost.org/patches/ .

Please find attached a diff against Boost 1.73 which was generated from bug fix commit https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653adc...

You would normally publish patches for the directory structure used in the release tarball. I.e. it should patch boost/outcome/experimental/status-code/status_code_ptr.hpp instead of include/status_code_ptr.hpp. Also, as a nitpick, could you consistently use underscores in the file and directory names?

Jonathan Wakely

11:35 a.m.

On Tue, 28 Apr 2020 at 12:30, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 2020-04-28 11:32, Niall Douglas via Boost wrote:

...
On 28/04/2020 01:08, Glen Fernandes wrote

...
Niall, if you want we can provide a Boost.Outcome patch on the 1.73 release notes (in similar fashion to the Coroutine patch on https://www.boost.org/users/history/version_1_72_0.html under Known Issues) and on https://www.boost.org/patches/ .

Please find attached a diff against Boost 1.73 which was generated from bug fix commit

https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653adc...

You would normally publish patches for the directory structure used in the release tarball. I.e. it should patch boost/outcome/experimental/status-code/status_code_ptr.hpp instead of include/status_code_ptr.hpp.

Niall's attachment did match the release tarball directory structure. Obviously the git commit didn't, because that isn't the directory structure of the git repo. (I'll make sure that patch gets applied to the Fedora packages).

Niall Douglas

1:08 p.m.

On 28/04/2020 12:35, Jonathan Wakely via Boost wrote:

...

On Tue, 28 Apr 2020 at 12:30, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...
On 2020-04-28 11:32, Niall Douglas via Boost wrote:

...
On 28/04/2020 01:08, Glen Fernandes wrote

...
Niall, if you want we can provide a Boost.Outcome patch on the 1.73 release notes (in similar fashion to the Coroutine patch on https://www.boost.org/users/history/version_1_72_0.html under Known Issues) and on https://www.boost.org/patches/ .

Please find attached a diff against Boost 1.73 which was generated from bug fix commit

https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653adc...

You would normally publish patches for the directory structure used in the release tarball. I.e. it should patch boost/outcome/experimental/status-code/status_code_ptr.hpp instead of include/status_code_ptr.hpp.> Niall's attachment did match the release tarball directory structure. Obviously the git commit didn't, because that isn't the directory structure of the git repo.

(I'll make sure that patch gets applied to the Fedora packages).

Correct. It was the *attachment* to my email that contained the diff for Boost 1.73 release. Thanks Jonathan for the Fedora package application. Niall

Glen Fernandes

4:50 p.m.

On Tue, Apr 28, 2020 at 4:32 AM Niall Douglas wrote:

...

On 28/04/2020 01:08, Glen Fernandes wrote

...
Niall, if you want we can provide a Boost.Outcome patch on the 1.73 release notes (in similar fashion to the Coroutine patch on https://www.boost.org/users/history/version_1_72_0.html under Known Issues) and on https://www.boost.org/patches/ .

Please find attached a diff against Boost 1.73 which was generated from bug fix commit https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653adc...

Thanks for this, sorry for the bother.

Done: * https://www.boost.org/users/history/version_1_73_0.html * https://www.boost.org/patches/ * https://www.boost.org/patches/1_73_0/0001-outcome-assert.patch Glen

Tom Kent

23 Apr 23 Apr

9:45 p.m.

On Thu, Apr 23, 2020 at 8:53 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...

The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

The SHA256 checksums are as follows:

d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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

I had four failures attempting to build on windows. However, they were atypical in that the build stalled out and would not continue, rather than producing an error. The last items in the terminal before stalling out was something like: D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc140-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.0\libboost_wave-vc140-mt-s-x32-1_73.lib D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc140-mt-s-x32-1_73.lib 1 file(s) copied. It seemed to be generally in wave, however one time it failed in log. This example shows the problem during msvc-14.0, but I believe I also saw it in 14.1 one of the times. I had experienced something similar during the beta build, and after succeeding I was unable to reproduce it on the same computer, somehow related to caching? Very weird, and I don't think we should release while this is ongoing. On the fifth try, I was able to get a good build for all versions of visual studio I was attempting. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X 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 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. Full build logs can be found here: https://gist.github.com/teeks99/586e868be64464e474233d20d35de656 Tom

Jeff Garland

10:08 p.m.

1 platform, 3 compilers, 5 c++ versions - All successfully compile - Same warning profile as beta Mint5 - 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux g++9.2 (2a, 17, 14, 11, 98) g++7.5 (17, 14, 11, 98) clang6.0.0 (17, 14, 11, 98) Looks good. On Thu, Apr 23, 2020 at 2:54 PM Tom Kent via Boost wrote:

...

On Thu, Apr 23, 2020 at 8:53 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...
The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

The SHA256 checksums are as follows:

d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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

I had four failures attempting to build on windows. However, they were atypical in that the build stalled out and would not continue, rather than producing an error.

The last items in the terminal before stalling out was something like:

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc140-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy

D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.0\libboost_wave-vc140-mt-s-x32-1_73.lib

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc140-mt-s-x32-1_73.lib 1 file(s) copied.

It seemed to be generally in wave, however one time it failed in log. This example shows the problem during msvc-14.0, but I believe I also saw it in 14.1 one of the times. I had experienced something similar during the beta build, and after succeeding I was unable to reproduce it on the same computer, somehow related to caching? Very weird, and I don't think we should release while this is ongoing.

On the fifth try, I was able to get a good build for all versions of visual studio I was attempting.

toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X 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

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.

Full build logs can be found here: https://gist.github.com/teeks99/586e868be64464e474233d20d35de656

Tom

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Marshall Clow

24 Apr 24 Apr

3:50 p.m.

On Thu, Apr 23, 2020 at 2:45 PM Tom Kent wrote:

...

On Thu, Apr 23, 2020 at 8:53 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...
The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

The SHA256 checksums are as follows:

d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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

I had four failures attempting to build on windows. However, they were atypical in that the build stalled out and would not continue, rather than producing an error.

The last items in the terminal before stalling out was something like:

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc140-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.0\libboost_wave-vc140-mt-s-x32-1_73.lib

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc140-mt-s-x32-1_73.lib 1 file(s) copied.

It seemed to be generally in wave, however one time it failed in log. This example shows the problem during msvc-14.0, but I believe I also saw it in 14.1 one of the times. I had experienced something similar during the beta build, and after succeeding I was unable to reproduce it on the same computer, somehow related to caching? Very weird, and I don't think we should release while this is ongoing.

Tom -- Were these stalls in the tools (compiler, linker) or in the tests, or in your sample programs?

Tom Kent

8:42 p.m.

On Fri, Apr 24, 2020 at 10:50 AM Marshall Clow wrote:

...

On Thu, Apr 23, 2020 at 2:45 PM Tom Kent wrote:

...
On Thu, Apr 23, 2020 at 8:53 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...
The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

The SHA256 checksums are as follows:

d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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

I had four failures attempting to build on windows. However, they were atypical in that the build stalled out and would not continue, rather than producing an error.

The last items in the terminal before stalling out was something like:

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc140-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.0\libboost_wave-vc140-mt-s-x32-1_73.lib

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc140-mt-s-x32-1_73.lib 1 file(s) copied.

It seemed to be generally in wave, however one time it failed in log. This example shows the problem during msvc-14.0, but I believe I also saw it in 14.1 one of the times. I had experienced something similar during the beta build, and after succeeding I was unable to reproduce it on the same computer, somehow related to caching? Very weird, and I don't think we should release while this is ongoing.

Tom --

Were these stalls in the tools (compiler, linker) or in the tests, or in your sample programs?

I initially thought this might be in the compiler, but upon further investigation I think it is a problem with b2. When the hang happens, there are no cl.exe instances, just b2. I also saw it happen in msvc-14.2, again in/after wave: common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.2\cmake\boost_test_exec_monitor-1.73.0\libboost_test_exec_monitor-variant-vc142-mt-s-x32-1_73-static.cmake D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\test\build\msvc-14.2\release\link-static\runtime-link-static\threading-multi\libboost_test_exec_monitor-variant-vc142-mt-s-x32-1_73-static.cmake 1 file(s) copied. compile-c-c++ D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threading-multi\instantiate_re2c_lexer_str.obj instantiate_re2c_lexer_str.cpp compile-c-c++ D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threading-multi\instantiate_re2c_lexer.obj instantiate_re2c_lexer.cpp msvc.archive D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc142-mt-s-x32-1_73.lib boost-install.generate-cmake-variant- D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc142-mt-s-x32-1_73-static.cmake common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.2\cmake\boost_wave-1.73.0\libboost_wave-variant-vc142-mt-s-x32-1_73-static.cmake D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc142-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.2\libboost_wave-vc142-mt-s-x32-1_73.lib D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc142-mt-s-x32-1_73.lib 1 file(s) copied. Running this command: b2 -j%NUMBER_OF_PROCESSORS% --without-mpi --build-dir=D:\ReleaseBuild/bin.v2 --stage-libdir=lib32-msvc-14.2 --build-type=complete toolset=msvc-14.2 address-model=32 architecture=x86 stage

Tom Kent

26 Apr 26 Apr

1:02 p.m.

On Fri, Apr 24, 2020 at 3:42 PM Tom Kent wrote:

...

On Fri, Apr 24, 2020 at 10:50 AM Marshall Clow wrote:

...
On Thu, Apr 23, 2020 at 2:45 PM Tom Kent wrote:

...
On Thu, Apr 23, 2020 at 8:53 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:

...
The first release candidates for the 1.73.0 release are now available at:

https://dl.bintray.com/boostorg/release/1.73.0/source/

The SHA256 checksums are as follows:

d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_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

I had four failures attempting to build on windows. However, they were atypical in that the build stalled out and would not continue, rather than producing an error.

The last items in the terminal before stalling out was something like:

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc140-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.0\libboost_wave-vc140-mt-s-x32-1_73.lib

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.0\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc140-mt-s-x32-1_73.lib 1 file(s) copied.

It seemed to be generally in wave, however one time it failed in log. This example shows the problem during msvc-14.0, but I believe I also saw it in 14.1 one of the times. I had experienced something similar during the beta build, and after succeeding I was unable to reproduce it on the same computer, somehow related to caching? Very weird, and I don't think we should release while this is ongoing.

Tom --

Were these stalls in the tools (compiler, linker) or in the tests, or in your sample programs?

I initially thought this might be in the compiler, but upon further investigation I think it is a problem with b2.

When the hang happens, there are no cl.exe instances, just b2.

I also saw it happen in msvc-14.2, again in/after wave: common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.2\cmake\boost_test_exec_monitor-1.73.0\libboost_test_exec_monitor-variant-vc142-mt-s-x32-1_73-static.cmake

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\test\build\msvc-14.2\release\link-static\runtime-link-static\threading-multi\libboost_test_exec_monitor-variant-vc142-mt-s-x32-1_73-static.cmake 1 file(s) copied. compile-c-c++ D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threading-multi\instantiate_re2c_lexer_str.obj instantiate_re2c_lexer_str.cpp compile-c-c++ D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threading-multi\instantiate_re2c_lexer.obj instantiate_re2c_lexer.cpp msvc.archive D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc142-mt-s-x32-1_73.lib boost-install.generate-cmake-variant- D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc142-mt-s-x32-1_73-static.cmake common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.2\cmake\boost_wave-1.73.0\libboost_wave-variant-vc142-mt-s-x32-1_73-static.cmake

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-variant-vc142-mt-s-x32-1_73-static.cmake 1 file(s) copied. common.copy D:\ReleaseBuild\boost_1_73_0\lib32-msvc-14.2\libboost_wave-vc142-mt-s-x32-1_73.lib

D:\ReleaseBuild\bin.v2\boost\bin.v2\libs\wave\build\msvc-14.2\release\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_wave-vc142-mt-s-x32-1_73.lib 1 file(s) copied.

Running this command: b2 -j%NUMBER_OF_PROCESSORS% --without-mpi --build-dir=D:\ReleaseBuild/bin.v2 --stage-libdir=lib32-msvc-14.2 --build-type=complete toolset=msvc-14.2 address-model=32 architecture=x86 stage

So I've tried hundreds of more runs with b2 -j%NUMBER_OF_PROCESSORS% --without-mpi --build-dir=D:\ReleaseBuild/bin.v2 --stage-libdir=lib32-msvc-14.2 variant=release link=static runtime-link=stastic toolset=msvc-14.2 address-model=32 architecture=x86 stage And haven't been able to reproduce with just that. Maybe it is something with my build process? Maybe something with the new `--stage-libdir=` flag? Either way, I'm changing my mind and thinking this shouldn't hold up the release. Tom

Glen Fernandes

24 Apr 24 Apr

3:18 a.m.

On Thu, Apr 23, 2020 at 9:53 AM Marshall Clow wrote:

...

The first release candidates for the 1.73.0 release are now available at: https://dl.bintray.com/boostorg/release/1.73.0/source/

Built successfully on Fedora 31 x86_64 with: * gcc 9.3.1: c++03/11/14/17/2a * clang 9.0.1: c++03/11/14/17/2a Glen

1657

Age (days ago)

1662

Last active (days ago)

List overview

Download

22 comments

9 participants

participants (9)

Andrey Semashev
Deniz Bahadir
Glen Fernandes
Jeff Garland
John Maddock
Jonathan Wakely
Marshall Clow
Niall Douglas
Tom Kent