[release] Boost 1.74.0 Release Candidate 1
The first release candidates for the 1.74.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.74.0/source/> The SHA256 checksums are as follows: 9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9 boost_1_74_0_rc1.7z 8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0 boost_1_74_0_rc1.tar.bz2 a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2 boost_1_74_0_rc1.tar.gz d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842 boost_1_74_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
On Fri, Aug 7, 2020 at 10:13 AM Marshall Clow via Boost-users < boost-users@lists.boost.org> wrote:
The first release candidates for the 1.74.0 release are now available at:
<https://dl.bintray.com/boostorg/release/1.74.0/source/>
The SHA256 checksums are as follows:
9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9 boost_1_74_0_rc1.7z 8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0 boost_1_74_0_rc1.tar.bz2 a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2 boost_1_74_0_rc1.tar.gz d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842 boost_1_74_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
Looks good for the windows/visual studio build. 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/bc3e05569228187df4aae5dc671ecc3e Tom
On Aug 7, 2020, at 8:13 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
The first release candidates for the 1.74.0 release are now available at:
<https://dl.bintray.com/boostorg/release/1.74.0/source/ <https://dl.bintray.com/boostorg/release/1.74.0/source/>>
The SHA256 checksums are as follows:
9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9 boost_1_74_0_rc1.7z 8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0 boost_1_74_0_rc1.tar.bz2 a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2 boost_1_74_0_rc1.tar.gz d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842 boost_1_74_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.
I was able to successfully build the libraries on Mac OS 10.15 using: Apple clang version 11.0.3 (clang-1103.0.32.62) using C++03/11/14/17/2a And with a recent ToT clang using C++03/11/14/17/2a — Marshall
My compile report the RC: 1 platforms, 4 compilers, 5 c++ versions as applicable - All successfully compile, so pretty solid - gcc10.1 2a mode had 154 warnings - All in agreement the locale library has deprecated auto_ptr with copious warnings (most of the ~95 warnings on g++ compiles) - python auto_ptr is another source - this is a bit better than 1.73 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++10.1 (2a, 17, 14, 11, 98) g++9.2 (2a, 17, 14, 11, 98) g++7.5 (17, 14, 11, 98) clang6.0.0 (17, 14, 11, 98 On Sat, Aug 8, 2020 at 9:36 PM Marshall Clow via Boost < boost@lists.boost.org> wrote:
On Aug 7, 2020, at 8:13 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
The first release candidates for the 1.74.0 release are now available at:
https://dl.bintray.com/boostorg/release/1.74.0/source/>>
The SHA256 checksums are as follows:
9ea3fc8573413f4d4b2c4d448110b6cb0467df834304112e143c7edb09ae71e9
boost_1_74_0_rc1.7z
8b6c429a41f7cac1880594adf8d1d6f0cc1cf19f8980c6b86ac38ef8b3d8a4e0 boost_1_74_0_rc1.tar.bz2 a0a96a9bb3863863e034cafc825b2ddba4249c7d278b76df1277295e7c7afbf2 boost_1_74_0_rc1.tar.gz d4f31cce9d5fbd55691dc2f5fb73380e95aa66426c891ceb3ebdfc6616022842 boost_1_74_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.
I was able to successfully build the libraries on Mac OS 10.15 using: Apple clang version 11.0.3 (clang-1103.0.32.62) using C++03/11/14/17/2a
And with a recent ToT clang using C++03/11/14/17/2a
— Marshall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi all, On 2020-08-11 9:41 a.m., Jeff Garland via Boost wrote:
My compile report the RC:
1 platforms, 4 compilers, 5 c++ versions as applicable - All successfully compile, so pretty solid - gcc10.1 2a mode had 154 warnings - All in agreement the locale library has deprecated auto_ptr with copious warnings (most of the ~95 warnings on g++ compiles) - python auto_ptr is another source - this is a bit better than 1.73
Does boost have a mechanism (compilation flags, auto-defined macro, etc.) to mask `std::auto_ptr` usage ? Note that the situation isn't quite as simple as replacing library-internal use of `std::auto_ptr`. For example, in case of Boost.Python we also need to specialize templates so users can continue using `std::auto_ptr` in their own code, unless they explicitly (using macros) or implicitly (using modern compilers) disable such backward-compatible support. I suppose there are other Boost libraries in a similar situation. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Aug 11, 2020 at 6:52 AM Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
Hi all,
On 2020-08-11 9:41 a.m., Jeff Garland via Boost wrote:
My compile report the RC:
Does boost have a mechanism (compilation flags, auto-defined macro, etc.) to mask `std::auto_ptr` usage ?
Note that the situation isn't quite as simple as replacing library-internal use of `std::auto_ptr`. For example, in case of Boost.Python we also need to specialize templates so users can continue using `std::auto_ptr` in their own code, unless they explicitly (using macros) or implicitly (using modern compilers) disable such backward-compatible support. I suppose there are other Boost libraries in a similar situation.
Here's a sample of the warnings -- looks to me like the python case all the warnings come from detail - so for modes past c++11 I'd think unique_ptr could be used. A macro for python could allow users to override the removal and use auto_ptr in their code if they choose. And this problem is isolated to python and locale. ./boost/locale/localization_backend.hpp:116:59: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/locale/util.hpp:180:28: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] Jeff
On 2020-08-11 10:07 a.m., Jeff Garland via Boost wrote:
Here's a sample of the warnings -- looks to me like the python case all the warnings come from detail - so for modes past c++11 I'd think unique_ptr could be used. A macro for python could allow users to override the removal and use auto_ptr in their code if they choose. And this problem is isolated to python and locale.
./boost/locale/localization_backend.hpp:116:59: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/locale/util.hpp:180:28: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
Note that the usage in Boost.Python is already wrapped in `# if !defined(BOOST_NO_AUTO_PTR)` so in principle that code shouldn't be visible in C++14 and beyond. Hence my question. I'll investigate. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Aug 11, 2020 at 7:17 AM Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
Note that the usage in Boost.Python is already wrapped in
`# if !defined(BOOST_NO_AUTO_PTR)`
Interesting.
so in principle that code shouldn't be visible in C++14 and beyond. Hence my question.
I'll investigate.
You're right -- it looks like the logic is there. Maybe the is_auto_ptr.hpp just doesn't have it in the include path (it isn't there directly). config/libstdcpp3.hpp // std::auto_ptr isn't provided with _GLIBCXX_DEPRECATED=0 (GCC 4.5 and earlier) // or _GLIBCXX_USE_DEPRECATED=0 (GCC 4.6 and later). #if defined(BOOST_LIBSTDCXX11) # if BOOST_LIBSTDCXX_VERSION < 40600 # if !_GLIBCXX_DEPRECATED # define BOOST_NO_AUTO_PTR # endif # elif !_GLIBCXX_USE_DEPRECATED # define BOOST_NO_AUTO_PTR # endif #endif Jeff
On Tue, Aug 11, 2020 at 7:46 AM Jeff Garland <azswdude@gmail.com> wrote:
On Tue, Aug 11, 2020 at 7:17 AM Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
Note that the usage in Boost.Python is already wrapped in
`# if !defined(BOOST_NO_AUTO_PTR)`
Interesting.
so in principle that code shouldn't be visible in C++14 and beyond. Hence my question.
I'll investigate.
You're right -- it looks like the logic is there. Maybe the is_auto_ptr.hpp just doesn't have it in the include path (it isn't there directly).
config/libstdcpp3.hpp
btw I did this experiment and it didn't work so something else non obvious is happening. Jeff
On Tue, 11 Aug 2020 at 15:08, Jeff Garland via Boost <boost@lists.boost.org> wrote:
On Tue, Aug 11, 2020 at 6:52 AM Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
Hi all,
On 2020-08-11 9:41 a.m., Jeff Garland via Boost wrote:
My compile report the RC:
Does boost have a mechanism (compilation flags, auto-defined macro, etc.) to mask `std::auto_ptr` usage ?
Note that the situation isn't quite as simple as replacing library-internal use of `std::auto_ptr`. For example, in case of Boost.Python we also need to specialize templates so users can continue using `std::auto_ptr` in their own code, unless they explicitly (using macros) or implicitly (using modern compilers) disable such backward-compatible support. I suppose there are other Boost libraries in a similar situation.
Here's a sample of the warnings -- looks to me like the python case all the warnings come from detail - so for modes past c++11 I'd think unique_ptr could be used. A macro for python could allow users to override the removal and use auto_ptr in their code if they choose. And this problem is isolated to python and locale.
./boost/locale/localization_backend.hpp:116:59: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/locale/util.hpp:180:28: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] ./boost/python/detail/is_auto_ptr.hpp:17:40: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
Those boost headers could use: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" ... #pragma GCC diagnostic pop around the uses of auto_ptr. That will prevent warnings coming from those uses. If users use auto_ptr in their own code then surely those users should be responsible for disabling the warnings coming from their own code? If you use the pragmas above then they won't get warnings from the Boost headers, even if they pass their auto_ptr objects to the Boost functions. They'd only get warnings for their own uses of auto_ptr in their own code, which as I said, is their concern not Boost's.
On Fri, Aug 7, 2020 at 8:14 AM Marshall Clow via Boost-users <boost-users@lists.boost.org> wrote:
The first release candidates for the 1.74.0 release are now available at:
There's a fix for the warning in Boost.Coroutine, merged to master - is it possible to include this in the release? See: <https://github.com/boostorg/coroutine/pull/55> Thanks
participants (6)
-
Jeff Garland -
Jonathan Wakely -
Marshall Clow -
Stefan Seefeld -
Tom Kent -
Vinnie Falco