[release] Boost 1.67.0 Beta 1
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
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
-----Original Message----- From: Boost-users <boost-users-bounces@lists.boost.org> 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 <dnljms@gmail.com> 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
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
On 20 March 2018 at 08:55, Rainer Deyke via Boost-users <boost-users@lists.boost.org> 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.
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 <boost-users@lists.boost.org> 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
On 21 March 2018 at 12:48, Olivier Tristan via Boost-users <boost-users@lists.boost.org> 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.
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
-----Original Message----- From: Boost-users <boost-users-bounces@lists.boost.org> 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 <dnljms@gmail.com> 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
On Mon, Mar 19, 2018 at 6: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/>
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
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?
On Mon, Mar 26, 2018 at 3:46 PM, Gavin Lambert via Boost-users <boost-users@lists.boost.org> 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
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
On 3 April 2018 at 19:19, Gregor Jasny via Boost-users <boost-users@lists.boost.org> 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.
On 4 April 2018 at 13:07, Daniel James <dnljms@gmail.com> wrote:
On 3 April 2018 at 19:19, Gregor Jasny via Boost-users <boost-users@lists.boost.org> 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:
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/
participants (3)
-
Daniel James -
Gavin Lambert -
Gregor Jasny -
Marcel Raad -
Olivier Tristan -
Raffi Enficiaud -
Rainer Deyke -
Tom Kent -
Vinnie Falco