Boost 1.65.0 Release Candidate 3
The third (and hopefully final) release candidates for the 1.65.0 release
are now available at:
https://dl.bintray.com/boostorg/release/1.65.0/source/
[ Note: The RC1s and RC2s are in that directory, too - make sure you get
the right files! ]
Changes since RC2:
* Fix a crashing bug in Boost.ASIO
* Fix a compilation error when including both
On Mon, Aug 14, 2017 at 2:35 PM, Marshall Clow
The third (and hopefully final) release candidates for the 1.65.0 release are now available at:
[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.
* Builds successfully with Apple Clang [Apple LLVM version 8.0.0 (clang-800.0.42.1)] with C++03/11/14/1z * Builds successfully with Clang Trunk [clang version 6.0.0 (trunk 310587)] with C++03/11/14 * Built successfully with Clang Trunk [clang version 6.0.0 (trunk 310587)] with C++1z except for Boost.Locale. -- Marshall
On 14 August 2017 at 23:35, Marshall Clow via Boost
The third (and hopefully final) release candidates for the 1.65.0 release are now available at:
[...]
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.
Thanks!
-- The release managers
As an exercise in bleeding the edges, I tried Visual Studio 2017.3 (released today) with Boost 1.64 and 1.65-rc3 and the main issue so far is a version detection failure in boost.config: https://github.com/boostorg/config/issues/176 I'll post a complete log there once it's done. I suppose it should not prevent releasing the version? Joël Lamotte
On 15 August 2017 at 05:08, Klaim - Joël Lamotte via Boost < boost@lists.boost.org> wrote:
As an exercise in bleeding the edges, I tried Visual Studio 2017.3
How to update 2017.2/.1/.0: https://docs.microsoft.com/en-gb/visualstudio/install/update-visual-studio -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
On Mon, Aug 14, 2017 at 4:35 PM, Marshall Clow via Boost < boost@lists.boost.org> wrote:
The third (and hopefully final) release candidates for the 1.65.0 release are now available at:
https://dl.bintray.com/boostorg/release/1.65.0/source/
[ Note: The RC1s and RC2s are in that directory, too - make sure you get the right files! ]
Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both
* An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17
The SHA256 checksums are as follows:
1d844a958656e76b140292ec1cbfe770d9916166c16e13b59d3dac1df3b7ef40 boost_1_65_0_rc3.7z 3fc2877cf5da4bbb0c91eab058d2e6764155e705e9c3e2dce2a0248936079675 boost_1_65_0_rc3.tar.bz2 e065b53d7f5326cc20d246b518facedb4407391aaf9fd4a1c90001e0c85accab boost_1_65_0_rc3.tar.gz 96b2ba69c6045060d1dfe012218457870200c2c22af60eb855bab5ffb75c13a2 boost_1_65_0_rc3.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.
Windows/Visual Studio builds look good. toolset arch compile Link Execute msvc-8.0 32 X X X msvc-8.0 64 X X X msvc-9.0 32 X X X msvc-9.0 64 X X X 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 Compile means that the b2 command completed without errors Install means that the installers for the respective version were generated 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
On 2017-08-14 23:35, Marshall Clow via Boost 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.
boost/math_fwd.hpp is now working for me, thanks a lot!
However I maybe found another regression introduced after the 1.64
release, this time in Boost.Thread (with pthread implementation and
BOOST_HAS_NANOSLEEP). A minimal example:
#include
nanosleep({0, 999366710}, NULL)
into
nanosleep({1501988898, 350057596}, [stuck for a very long time]
. If the sleep is called inside a boost::thread, hidden::sleep_until is implemented via condition.do_wait_until instead of nanosleep, this works. For me a slightly extended test code works as expected if compiled in debug mode but is stuck in release mode. I'm testing under Linux with GCC 7.1 and a Clang++ 5.0.0 snapshot.
On 8/15/2017 6:10 AM, Peppard via Boost wrote:
However I maybe found another regression introduced after the 1.64 release, this time in Boost.Thread (with pthread implementation and BOOST_HAS_NANOSLEEP). A minimal example:
#include
int main() { boost::this_thread::sleep(boost::posix_time::seconds(1)); }
This sleeps "forever", however a slightly more complicated program might not. I bisected it to this commit: https://github.com/boostorg/thread/commit/d4cff01c724f1355fef0990f3d6d678e52...
The problem seems to be the BOOST_THREAD_USEFIXES_TIMESPEC define, which alters some internal behavior, effectively changing
nanosleep({0, 999366710}, NULL)
into
nanosleep({1501988898, 350057596}, [stuck for a very long time]
. If the sleep is called inside a boost::thread, hidden::sleep_until is implemented via condition.do_wait_until instead of nanosleep, this works. For me a slightly extended test code works as expected if compiled in debug mode but is stuck in release mode. I'm testing under Linux with GCC 7.1 and a Clang++ 5.0.0 snapshot.
This bug was fixed in the develop branch a couple weeks ago. https://github.com/boostorg/thread/pull/127 (At least it looks like the same bug. I never tracked down the commit that introduced the bug, or figured out whether or not it was a regression.) -- David Olsen NVIDIA - PGI
On 2017-08-15 19:45, David Olsen via Boost wrote:
On 8/15/2017 6:10 AM, Peppard via Boost wrote:
However I maybe found another regression introduced after the 1.64 release, this time in Boost.Thread (with pthread implementation and BOOST_HAS_NANOSLEEP). A minimal example:
#include
int main() { boost::this_thread::sleep(boost::posix_time::seconds(1)); }
This sleeps "forever", however a slightly more complicated program might not. I bisected it to this commit: https://github.com/boostorg/thread/commit/d4cff01c724f1355fef0990f3d6d678e52...
The problem seems to be the BOOST_THREAD_USEFIXES_TIMESPEC define, which alters some internal behavior, effectively changing
nanosleep({0, 999366710}, NULL)
into
nanosleep({1501988898, 350057596}, [stuck for a very long time]
. If the sleep is called inside a boost::thread, hidden::sleep_until is implemented via condition.do_wait_until instead of nanosleep, this works. For me a slightly extended test code works as expected if compiled in debug mode but is stuck in release mode. I'm testing under Linux with GCC 7.1 and a Clang++ 5.0.0 snapshot.
This bug was fixed in the develop branch a couple weeks ago. https://github.com/boostorg/thread/pull/127 (At least it looks like the same bug. I never tracked down the commit that introduced the bug, or figured out whether or not it was a regression.)
Looks like this fixes the bug, but as you said, only in develop. And even with the fix, I get the impression that the library is in a experimental/unstable state with all the time/clock changes over the past months. There is even commented out code in some places. And we have timespec_now() vs timespec_now_realtime(), the first one being used only when BOOST_THREAD_USEFIXES_TIMESPEC is not defined, but if it's not defined, the code of timespec_now and timespec_now_realtime is the same, right? Do I miss something? Anyway, as it stands, it looks like rc3 thread lib does not pass its own test suite (stuck e.g. in ex_tennis). Isn't passing the regression test suite (at least for major platforms) a requirement for an official release?
Le 16/08/2017 à 01:13, Peppard via Boost a écrit :
However I maybe found another regression introduced after the 1.64 release, this time in Boost.Thread (with pthread implementation and BOOST_HAS_NANOSLEEP). A minimal example:
#include
int main() { boost::this_thread::sleep(boost::posix_time::seconds(1)); }
This sleeps "forever", however a slightly more complicated program might not. I bisected it to this commit: https://github.com/boostorg/thread/commit/d4cff01c724f1355fef0990f3d6d678e52...
The problem seems to be the BOOST_THREAD_USEFIXES_TIMESPEC define, which alters some internal behavior, effectively changing
nanosleep({0, 999366710}, NULL) into
nanosleep({1501988898, 350057596}, [stuck for a very long time] . If the sleep is called inside a boost::thread, hidden::sleep_until is implemented via condition.do_wait_until instead of nanosleep, this works. For me a slightly extended test code works as expected if compiled in debug mode but is stuck in release mode. I'm testing under Linux with GCC 7.1 and a Clang++ 5.0.0 snapshot. This bug was fixed in the develop branch a couple weeks ago. https://github.com/boostorg/thread/pull/127 (At least it looks like the same bug. I never tracked down the commit
On 8/15/2017 6:10 AM, Peppard via Boost wrote: that introduced the bug, or figured out whether or not it was a regression.) Looks like this fixes the bug, but as you said, only in develop. And even with the fix, Thanks for checking. I get the impression that the library is in a experimental/unstable state with all the time/clock changes over the
On 2017-08-15 19:45, David Olsen via Boost wrote: past months. There is even commented out code in some places. And we have timespec_now() vs timespec_now_realtime(), the first one being used only when BOOST_THREAD_USEFIXES_TIMESPEC is not defined, but if it's not defined, the code of timespec_now and timespec_now_realtime is the same, right? Do I miss something? You are right that I have had a lot of trouble lastly with timeout issues. Iwill see what can I do this evening.
Anyway, as it stands, it looks like rc3 thread lib does not pass its own test suite (stuck e.g. in ex_tennis). Isn't passing the regression test suite (at least for major platforms) a requirement for an official release? Vicente
A month ago, I have reported a release-tools' issue regarding malformed json for release files: https://github.com/boostorg/release-tools/issues/3 It did get attention by Rene (I think), but it has not been fixed yet. If we are going for RC4, could you merge this too? The fix is trivial (just deleting 1 character), so it won't be that hard. I'm having problems with automated checksum validation for my CI server, because I can't feed this file to a formal JSON parser. Nana 2017-08-16 20:43 GMT+09:00 Vicente J. Botet Escriba via Boost < boost@lists.boost.org>:
Le 16/08/2017 à 01:13, Peppard via Boost a écrit :
On 2017-08-15 19:45, David Olsen via Boost wrote:
On 8/15/2017 6:10 AM, Peppard via Boost wrote:
However I maybe found another regression introduced after the 1.64 release, this time in Boost.Thread (with pthread implementation and BOOST_HAS_NANOSLEEP). A minimal example:
#include
int main() { boost::this_thread::sleep(boost::posix_time::seconds(1)); }
This sleeps "forever", however a slightly more complicated program might not. I bisected it to this commit: https://github.com/boostorg/thread/commit/d4cff01c724f1355fe f0990f3d6d678e52f61fd0
The problem seems to be the BOOST_THREAD_USEFIXES_TIMESPEC define, which alters some internal behavior, effectively changing
nanosleep({0, 999366710}, NULL)
into
nanosleep({1501988898, 350057596}, [stuck for a very long time]
. If the sleep is called inside a boost::thread, hidden::sleep_until is implemented via condition.do_wait_until instead of nanosleep, this works. For me a slightly extended test code works as expected if compiled in debug mode but is stuck in release mode. I'm testing under Linux with GCC 7.1 and a Clang++ 5.0.0 snapshot.
This bug was fixed in the develop branch a couple weeks ago. https://github.com/boostorg/thread/pull/127 (At least it looks like the same bug. I never tracked down the commit that introduced the bug, or figured out whether or not it was a regression.)
Looks like this fixes the bug, but as you said, only in develop. And even with the fix,
Thanks for checking.
I get the impression that the library is in a experimental/unstable state with all the time/clock changes over the past months. There is even commented out code in some places. And we have timespec_now() vs timespec_now_realtime(), the first one being used only when BOOST_THREAD_USEFIXES_TIMESPEC is not defined, but if it's not defined, the code of timespec_now and timespec_now_realtime is the same, right? Do I miss something?
You are right that I have had a lot of trouble lastly with timeout issues. Iwill see what can I do this evening.
Anyway, as it stands, it looks like rc3 thread lib does not pass its own test suite (stuck e.g. in ex_tennis). Isn't passing the regression test suite (at least for major platforms) a requirement for an official release?
Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
On Wed, Aug 16, 2017 at 4:54 PM, Nana Sakisaka via Boost < boost@lists.boost.org> wrote:
A month ago, I have reported a release-tools' issue regarding malformed json for release files:
https://github.com/boostorg/release-tools/issues/3
It did get attention by Rene (I think), but it has not been fixed yet. If we are going for RC4, could you merge this too? The fix is trivial (just deleting 1 character), so it won't be that hard.
No; sorry. :-( Not because it's hard - but because I just pushed RC4. I'll fix the tool right now, though. -- Marshall
On Wed, Aug 16, 2017 at 5:01 PM, Marshall Clow
On Wed, Aug 16, 2017 at 4:54 PM, Nana Sakisaka via Boost < boost@lists.boost.org> wrote:
A month ago, I have reported a release-tools' issue regarding malformed json for release files:
https://github.com/boostorg/release-tools/issues/3
It did get attention by Rene (I think), but it has not been fixed yet. If we are going for RC4, could you merge this too? The fix is trivial (just deleting 1 character), so it won't be that hard.
No; sorry. :-( Not because it's hard - but because I just pushed RC4.
I'll fix the tool right now, though.
Committed on develop. -- Marshall
Le 14.08.17 à 23:35, Marshall Clow via Boost a écrit :
The third (and hopefully final) release candidates for the 1.65.0 release are now available at:
https://dl.bintray.com/boostorg/release/1.65.0/source/
[ Note: The RC1s and RC2s are in that directory, too - make sure you get the right files! ]
Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both
* An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17
The SHA256 checksums are as follows:
1d844a958656e76b140292ec1cbfe770d9916166c16e13b59d3dac1df3b7ef40 boost_1_65_0_rc3.7z 3fc2877cf5da4bbb0c91eab058d2e6764155e705e9c3e2dce2a0248936079675 boost_1_65_0_rc3.tar.bz2 e065b53d7f5326cc20d246b518facedb4407391aaf9fd4a1c90001e0c85accab boost_1_65_0_rc3.tar.gz 96b2ba69c6045060d1dfe012218457870200c2c22af60eb855bab5ffb75c13a2 boost_1_65_0_rc3.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.
On my side, tested on Ubuntu 14.04 gcc4.8.4, OSX10.10 (Apple LLVM version 6.0) and VS2015 & 2017. All projects compile fine. On VS2015 & 2017, I need this patch to fix a compilation error on a project using boost.python: https://github.com/boostorg/python/commit/b3b67273b0751ccfe650cbaebc053bcd32... Thanks, Raffi
participants (9)
-
David Olsen -
degski -
Klaim - Joël Lamotte -
Marshall Clow -
Nana Sakisaka -
Peppard -
Raffi Enficiaud -
Tom Kent -
Vicente J. Botet Escriba