[release] Boost 1.67.0 Beta 1

newer
[asio] SSL async_shutdown() never...

older
Pointer Container Library changes...

Daniel James

19 Mar 2018 19 Mar '18

1:28 p.m.

Boost release 1.67.0 beta 1 is now available at: https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/ The SHA256 checksums are as follows: 154cf490da858fd9c2307bb904b07a42cbe8355ecf99d5477f0d843c6d03cdda boost_1_67_0_b1.7z 0d854b208fefaeb5837d6c417f505b189275e32d017f6226001fb165a5ac51ed boost_1_67_0_b1.tar.bz2 6eb3f9ca8db355765f41361e1e26976228f0c2dff400aade8a5e97aec6aa59f4 boost_1_67_0_b1.tar.gz 678a6459f2517932536ec97297be1de46ea073f2e2ee17ec8397b80aa0953f49 boost_1_67_0_b1.zip For details of what's in the release, see http://www.boost.org/users/history/version_1_67_0.html. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

Show replies by date

Tom Kent

19 Mar 19 Mar

2:27 p.m.

On Mon, Mar 19, 2018 at 8:28 AM, Daniel James via Boost-users < boost-users@lists.boost.org> wrote:

...

Boost release 1.67.0 beta 1 is now available at:

https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/

The SHA256 checksums are as follows:

154cf490da858fd9c2307bb904b07a42cbe8355ecf99d5477f0d843c6d03cdda boost_1_67_0_b1.7z 0d854b208fefaeb5837d6c417f505b189275e32d017f6226001fb165a5ac51ed boost_1_67_0_b1.tar.bz2 6eb3f9ca8db355765f41361e1e26976228f0c2dff400aade8a5e97aec6aa59f4 boost_1_67_0_b1.tar.gz 678a6459f2517932536ec97297be1de46ea073f2e2ee17ec8397b80aa0953f49 boost_1_67_0_b1.zip

For details of what's in the release, see http://www.boost.org/users/history/version_1_67_0.html.

Please download the beta, give it a try, and report any problems you encounter.

Thanks,

-- The Boost Release Team

Windows binaries are also available here: https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/binaries/ Tom

Marcel Raad

7:24 p.m.

...

-----Original Message----- From: Boost-users On Behalf Of Daniel James via Boost-users Sent: Montag, 19. März 2018 14:28 To: boost@lists.boost.org; boost-users@lists.boost.org Cc: Daniel James Subject: [Boost-users] [release] Boost 1.67.0 Beta 1

Boost release 1.67.0 beta 1 is now available at: [...] Please download the beta, give it a try, and report any problems you encounter.

Compilation of Signals2 with BOOST_USE_WINDOWS_H is broken because of https://github.com/boostorg/signals2/commit/f801fa8f645308296f41c6a59851aacb...: boost\signals2\detail\lwm_win32_cs.hpp(90,26): error C2039: 'InitializeCriticalSection': is not a member of 'boost::signals2' boost\signals2\detail\lwm_win32_cs.hpp(96,26): error C2039: 'DeleteCriticalSection': is not a member of 'boost::signals2' boost\signals2\detail\lwm_win32_cs.hpp(101,26): error C2039: 'EnterCriticalSection': is not a member of 'boost::signals2' boost\signals2\detail\lwm_win32_cs.hpp(107,33): error C2039: 'TryEnterCriticalSection': is not a member of 'boost::signals2' boost\signals2\detail\lwm_win32_cs.hpp(118,26): error C2039: 'LeaveCriticalSection': is not a member of 'boost::signals2' With BOOST_USE_WINDOWS_H, these functions are in the global namespace. Marcel

Rainer Deyke

20 Mar 20 Mar

8:55 a.m.

I see that boost/next_prior.hpp has been removed from boost/utility.hpp. Since this is a breaking change, maybe it should be added to the release notes. -- Rainer Deyke - rainerd@eldwood.com

Daniel James

21 Mar 21 Mar

11:46 a.m.

On 20 March 2018 at 08:55, Rainer Deyke via Boost-users wrote:

...

I see that boost/next_prior.hpp has been removed from boost/utility.hpp. Since this is a breaking change, maybe it should be added to the release notes.

I've added a note. Thanks.

Olivier Tristan

12:48 p.m.

Is this commit included ? https://github.com/boostorg/filesystem/commit/e3976fb3d3e7fdff668acb6deb6150... I see no mention of this crash fix in the changelog. Thanks ! 2018-03-21 12:46 GMT+01:00 Daniel James via Boost-users < boost-users@lists.boost.org>:

...

On 20 March 2018 at 08:55, Rainer Deyke via Boost-users wrote:

...
I see that boost/next_prior.hpp has been removed from boost/utility.hpp. Since this is a breaking change, maybe it should be added to the release notes.

I've added a note. Thanks. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Olivier Tristan Research & Development www.uvi.net

Daniel James

1:01 p.m.

On 21 March 2018 at 12:48, Olivier Tristan via Boost-users wrote:

...

Is this commit included ? https://github.com/boostorg/filesystem/commit/e3976fb3d3e7fdff668acb6deb6150...

I see no mention of this crash fix in the changelog.

It looks like it's included.

Raffi Enficiaud

22 Mar 22 Mar

midnight

Le 19/03/2018 à 14:28, Daniel James via Boost-users a écrit :

...

Boost release 1.67.0 beta 1 is now available at:

https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/

The SHA256 checksums are as follows:

154cf490da858fd9c2307bb904b07a42cbe8355ecf99d5477f0d843c6d03cdda boost_1_67_0_b1.7z 0d854b208fefaeb5837d6c417f505b189275e32d017f6226001fb165a5ac51ed boost_1_67_0_b1.tar.bz2 6eb3f9ca8db355765f41361e1e26976228f0c2dff400aade8a5e97aec6aa59f4 boost_1_67_0_b1.tar.gz 678a6459f2517932536ec97297be1de46ea073f2e2ee17ec8397b80aa0953f49 boost_1_67_0_b1.zip

For details of what's in the release, see http://www.boost.org/users/history/version_1_67_0.html.

Please download the beta, give it a try, and report any problems you encounter.

Thanks,

-- The Boost Release Team

I just committed 4a5f98ba6049dbdb886f55777d54eff77e19982b to Boost.Test / master branch, contains a minor bug fix + documentation enhancements. Let me know if this can go to the final release. Thanks, Raffi

Marcel Raad

23 Mar 23 Mar

8:38 a.m.

...

-----Original Message----- From: Boost-users On Behalf Of Daniel James via Boost-users Sent: Montag, 19. März 2018 14:28 To: boost@lists.boost.org; boost-users@lists.boost.org Cc: Daniel James Subject: [Boost-users] [release] Boost 1.67.0 Beta 1

Boost release 1.67.0 beta 1 is now available at: [...]

Please download the beta, give it a try, and report any problems you encounter.

I just noticed a breaking change: boost::uuids::random_generator is not copyable anymore. Is that is on purpose, it should maybe be mentioned in the release notes. Marcel

Vinnie Falco

1:51 p.m.

On Mon, Mar 19, 2018 at 6:28 AM, Daniel James via Boost-users wrote:

...

Boost release 1.67.0 beta 1 is now available at:

https://dl.bintray.com/boostorg/beta/1.67.0.beta.1/source/

A user discovered a defect in Beast. A recent change switched calls to boost::asio::post from the 2-argument version to the 1-argument version in order to simplify code and remove a redundant function call. Unfortunately this change was not safe, as it exposed a problem where Beast composed operations do not strictly adhere to the requirements of Networking.TS. Specifically that Beast composed operations should maintain the existence of an executor_work_guard for the I/O executor (not to be confused with the completion handler's associated executor). The switch to the 1-argument version of post() was made recently, and a user discovered that this broke the functionality of using asynchronous stream algorithms with futures. The simplest fix is to revert the offending commit, which I have done here and would like to merge to master for 1.67: https://github.com/boostorg/beast/pull/1075 A more robust fix, which changes all composed operation implementations to maintain the lifetime of an executor_work_guard attached to the I/O context executor will be forthcoming after the 1.67 release. Reverting the commit is less risky than performing the robust fix for the release, and also note that Asio's own composed operations need this treatment as well. The Boost.Asio author was extremely helpful in identifying the problem and explaining the new requirements for composed operations. Thanks

Gavin Lambert

26 Mar 26 Mar

10:46 p.m.

On 24/03/2018 02:51, Vinnie Falco wrote:

...

A user discovered a defect in Beast. A recent change switched calls to boost::asio::post from the 2-argument version to the 1-argument version in order to simplify code and remove a redundant function call. Unfortunately this change was not safe, as it exposed a problem where Beast composed operations do not strictly adhere to the requirements of Networking.TS. Specifically that Beast composed operations should maintain the existence of an executor_work_guard for the I/O executor (not to be confused with the completion handler's associated executor).

Out of curiosity, do you have any link to discussion or documents that explain the reasoning and/or motivation for this? I would have assumed that composed operations should not need the equivalent of io_service::work because work should be considered in-progress from the time that it is originally posted until such time as the completion handler *finishes* executing (thus if the completion handler posts additional work, there is no "gap"). That's certainly how Asio has historically worked. You only need an explicit work guard if there are times when you have no outstanding work (eg. you let a completion handler exit without posting something new, or you run your io_service/io_context before you post your first operation). Or is that last comment indicating that you're using two separate io_services, so you do have times where operations aren't pending on one or the other?

Vinnie Falco

27 Mar 27 Mar

12:08 a.m.

On Mon, Mar 26, 2018 at 3:46 PM, Gavin Lambert via Boost-users wrote:

...

Out of curiosity, do you have any link to discussion or documents that explain the reasoning and/or motivation for this?

The discussion took place privately via email unfortunately.

...

I would have assumed that composed operations should not need the equivalent of io_service::work because work should be considered in-progress from the time that it is originally posted until such time as the completion handler *finishes* executing (thus if the completion handler posts additional work, there is no "gap").

The composed operation might not call any initiating function and instead choose to complete immediately, via boost::asio::post. In Beast for example, this can happen on an HTTP read when the caller's buffer already has a complete message (no I/O is performed in this case).

...

That's certainly how Asio has historically worked. You only need an explicit work guard if there are times when you have no outstanding work (eg. you let a completion handler exit without posting something new, or you run your io_service/io_context before you post your first operation).

In Net.TS (and by extension, Net.TS-flavored Boost.Asio) work guards are associated with executors not the io_context. There are two executors at play here: 1. The executor of the io_context associated with the I/O object 2. The handler's associated executor (obtained by get_associated_executor) The 2-argument form of boost::asio::post creates the executor_work_guard for the handler's associated executor, but the composed operation is responsible for either directly or indirectly maintaining the lifetime of an executor_work_guard for the io_context's executor. This is described in [async.reqmts.async.work]: 13.2.7.10 Outstanding work Until the asynchronous operation has completed, the asynchronous operation shall maintain: (1.1) — an object work1 of type executor_work_guard, initialized as work1(ex1), and where work1.owns_work() == true; and (1.2) — an object work2 of type executor_work_guard, initialized as work2(ex2), and where work2.owns_work() == true. See http://cplusplus.github.io/networking-ts/draft.pdf

...

Or is that last comment indicating that you're using two separate io_services, so you do have times where operations aren't pending on one or the other?

No, there is only one io_context, which is the io_context associated with the stream. There are two executors. Thanks

Gregor Jasny

3 Apr 3 Apr

6:19 p.m.

Hello, On 3/19/18 2:28 PM, Daniel James via Boost-users wrote:

...

Boost release 1.67.0 beta 1 is now available at: Please download the beta, give it a try, and report any problems you encounter.

I got a build warning in Python Jamfile which is fixed by: https://github.com/boostorg/python/commit/d515eb82c8a1e007651b1e7d75a3141fdc... I got this warning:

...

/Users/gjasny/Git/ExternalLibs/boost/libs/predef/check/../tools/check/predef.jam:46: Unescaped special character in argument $(language)::$(expression)

I got this error:

...

./b2 toolset=clang 'cxxflags=-arch i386 -arch x86_64'

...

/Users/gjasny/Git/ExternalLibs/boost/libs/predef/check/../tools/check/predef.jam:46: Unescaped special character in argument $(language)::$(expression) /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/configure.jam:288: in try-find-build *** argument error * rule log-check-result ( result ) * called with: ( ) * missing argument result /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/configure.jam:86:see definition of rule 'log-check-result' being called /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/configure.jam:391: in find-builds-raw /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/configure.jam:450: in configure.find-builds /Users/gjasny/Git/ExternalLibs/boost/boostcpp.jam:690: in boostcpp.deduce-address-model /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/kernel/modules.jam:107: in modules.call-in /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/util/indirect.jam:105: in indirect.call /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/property.jam:144: in property.evaluate-conditionals-in-context /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:1087: in evaluate-requirements /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:1121: in common-properties2 /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:1017: in targets.common-properties /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:1313: in alias-target-class.generate /Users/gjasny/Git/ExternalLibs/boost/boostcpp.jam:500: in build-multiple /Users/gjasny/Git/ExternalLibs/boost/boostcpp.jam:490: in class@top-level-target.generate /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:812: in generate-really /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:784: in class@main-target.generate /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build/targets.jam:273: in class@project-target.generate /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/build-system.jam:797: in load /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/kernel/modules.jam:295: in import /Users/gjasny/Git/ExternalLibs/boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /Users/gjasny/Git/ExternalLibs/boost/boost-build.jam:17: in module scope

I guess b2 when trying to deduce compiler settings stumbles over 'cxxflags=-arch i386 -arch x86_64'. In case that's accepted behavior, how could I specify architectures for a fat library? When compiling for Android with API level 14 (~Android 4.0.0) and NDK r16b I see the following error:

...

build 03-Apr-2018 04:49:18 clang-linux.compile.c++.without-pth /home/bamboo/bamboo-agent-home/xml-data/build-dir/EL-BOOST7-AC/_output/Applications_Android_armeabi-v7a_cxx14/boost/bin.v2/libs/log/build/clang-linux-android/debug/link-static/pch-off/target-os-android/threadapi-pthread/threading-multi/text_file_backend.o build 03-Apr-2018 04:49:18 In file included from libs/log/src/text_file_backend.cpp:61: build 03-Apr-2018 04:49:18 In file included from ./boost/thread/mutex.hpp:16: build 03-Apr-2018 04:49:18 In file included from ./boost/thread/pthread/mutex.hpp:26: build 03-Apr-2018 04:49:18 ./boost/thread/pthread/pthread_helpers.hpp:28:15: error: use of undeclared identifier 'pthread_condattr_setclock'; did you mean 'pthread_condattr_setpshared'? build 03-Apr-2018 04:49:18 pthread_condattr_setclock(&attr, CLOCK_MONOTONIC); build 03-Apr-2018 04:49:18 ^~~~~~~~~~~~~~~~~~~~~~~~~ build 03-Apr-2018 04:49:18 pthread_condattr_setpshared build 03-Apr-2018 04:49:18 /home/bamboo/bamboo-agent-home/xml-data/build-dir/EL-BOOST7-AC/_toolchain_arm_android-14/bin/../sysroot/usr/include/pthread.h:122:5: note: 'pthread_condattr_setpshared' declared here build 03-Apr-2018 04:49:18 int pthread_condattr_setpshared(pthread_condattr_t* __attr, int __shared); build 03-Apr-2018 04:49:18 ^ build 03-Apr-2018 04:49:18 1 error generated. build 03-Apr-2018 04:49:18 I'll have a look at the Android error myself, but would like to get some feedback for the b2 vs. -arch issue.

Thanks, Gregor

Daniel James

4 Apr 4 Apr

12:07 p.m.

On 3 April 2018 at 19:19, Gregor Jasny via Boost-users wrote:

...

I got this warning:

...
/Users/gjasny/Git/ExternalLibs/boost/libs/predef/check/../tools/check/predef.jam:46: Unescaped special character in argument $(language)::$(expression)

Sorry, it's a bit late to fix warnings. [snip]

...

I guess b2 when trying to deduce compiler settings stumbles over 'cxxflags=-arch i386 -arch x86_64'. In case that's accepted behavior, how could I specify architectures for a fat library?

I created a github issue for this: https://github.com/boostorg/build/issues/295

...

When compiling for Android with API level 14 (~Android 4.0.0) and NDK r16b I see the following error: [snip] I'll have a look at the Android error myself, but would like to get some feedback for the b2 vs. -arch issue.

Thanks, although it's unlikely we'll fix it in this release. Especially if it isn't a regression.

Daniel James

7 Apr 7 Apr

2:56 p.m.

On 4 April 2018 at 13:07, Daniel James wrote:

...

On 3 April 2018 at 19:19, Gregor Jasny via Boost-users wrote:

...
I guess b2 when trying to deduce compiler settings stumbles over 'cxxflags=-arch i386 -arch x86_64'. In case that's accepted behavior, how could I specify architectures for a fat library?

I created a github issue for this:

https://github.com/boostorg/build/issues/295

There's a commit on the develop branch of build which will hopefully fix this. If possible, can you test it? https://github.com/boostorg/build/commit/7ea55e4f2d782c17034cbc016b639d66fc5... You could manually update build in the beta release, but an easier way to test it might be to try the develop snapshot: https://dl.bintray.com/boostorg/develop/

2425

Age (days ago)

2444

Last active (days ago)

List overview

Download

14 comments

9 participants

participants (9)

Daniel James
Gavin Lambert
Gregor Jasny
Marcel Raad
Olivier Tristan
Raffi Enficiaud
Rainer Deyke
Tom Kent
Vinnie Falco