[release] Boost 1.66.0 Beta 1 Release Candidate 1

newer
[config] msvc-15.5, updating tests

older
[beast] Security Review: Hybrid...

Daniel James

16 Nov 2017 16 Nov '17

10:39 a.m.

The release candidates for the 1.66.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/ The SHA256 checksums are as follows: 0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip The in progress release notes are at: http://www.boost.org/users/history/in_progress.html And the documentation is at: http://www.boost.org/doc/libs/1_66_0_beta1/ 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.

Show replies by date

Tom Kent

16 Nov 16 Nov

2:36 p.m.

On Thu, Nov 16, 2017 at 4:39 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

The release candidates for the 1.66.0 beta release are now available at:

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

The SHA256 checksums are as follows:

0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip

The in progress release notes are at:

http://www.boost.org/users/history/in_progress.html

And the documentation is at:

http://www.boost.org/doc/libs/1_66_0_beta1/

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'm seeing compile errors in Boost Python against msvc-11.0 (10.0 and 12.0 work!). There are a lot of them, but they all seem to be related to this: compile-c-c++ bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj life_support.cpp .\boost/python/detail/type_traits.hpp(102) : error C2143: syntax error : missing ';' before '=' .\boost/python/detail/type_traits.hpp(102) : error C2873: 'true_' : symbol cannot be used in a using-declaration .\boost/python/detail/type_traits.hpp(102) : error C2513: 'int' : no variable declared before '=' .\boost/python/detail/type_traits.hpp(103) : error C2143: syntax error : missing ';' before '=' .\boost/python/detail/type_traits.hpp(103) : error C2873: 'false_' : symbol cannot be used in a using-declaration .\boost/python/detail/type_traits.hpp(103) : error C2513: 'int' : no variable declared before '=' call "C:\Users\tomkent\AppData\Local\Temp\2\b2_msvc_11.0_vcvarsall_amd64.cmd"

...

nul cl /Zm800 -nologo @"bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj.rsp"

...failed compile-c-c++ bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj... 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 FAIL msvc-11.0 64 FAIL 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 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. The full build log can be found here: https://gist.github.com/teeks99/3a8026b06cd53ef2746a4e08bff1a026

Stefan Seefeld

2:55 p.m.

Hi Tom, thanks for raising this issue. On 16.11.2017 09:36, Tom Kent via Boost wrote:

...

On Thu, Nov 16, 2017 at 4:39 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

...
The release candidates for the 1.66.0 beta release are now available at:

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

The SHA256 checksums are as follows:

0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip

The in progress release notes are at:

http://www.boost.org/users/history/in_progress.html

And the documentation is at:

http://www.boost.org/doc/libs/1_66_0_beta1/

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'm seeing compile errors in Boost Python against msvc-11.0 (10.0 and 12.0 work!).

There are a lot of them, but they all seem to be related to this:

compile-c-c++ bin.v2\libs\python\build\msvc-11.0\release\address-model-64\link-static\threadapi-win32\threading-multi\object\life_support.obj life_support.cpp .\boost/python/detail/type_traits.hpp(102) : error C2143: syntax error : missing ';' before '=' .\boost/python/detail/type_traits.hpp(102) : error C2873: 'true_' : symbol cannot be used in a using-declaration .\boost/python/detail/type_traits.hpp(102) : error C2513: 'int' : no variable declared before '=' .\boost/python/detail/type_traits.hpp(103) : error C2143: syntax error : missing ';' before '=' .\boost/python/detail/type_traits.hpp(103) : error C2873: 'false_' : symbol cannot be used in a using-declaration .\boost/python/detail/type_traits.hpp(103) : error C2513: 'int' : no variable declared before '='

...

= 11.0 , when it should in fact be 'true' for MSVC 11.0, too, this might explain the error. But given that I'm not very familiar with MSVC,

It looks like we falsely assume the compiler understands C++11 and thus use attempt to use std::integral_constant. Could it be that the conditional in https://github.com/boostorg/python/blob/develop/include/boost/python/detail/... is wrong ? (If it was set to 'true' for MSVC 10.0, and 'false' for MSVC this is pure speculation. I'd appreciate any help from some Windows experts.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

3:10 p.m.

Stefan Seefeld wrote:

...

It looks like we falsely assume the compiler understands C++11 and thus use attempt to use std::integral_constant. Could it be that the conditional in https://github.com/boostorg/python/blob/develop/include/boost/python/detail/... is wrong ?

You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless you have a specific reason not to do so.

Daniel James

3:21 p.m.

On 16 November 2017 at 15:10, Peter Dimov via Boost wrote:

...

Stefan Seefeld wrote:

...
It looks like we falsely assume the compiler understands C++11 and thus use attempt to use std::integral_constant. Could it be that the conditional in https://github.com/boostorg/python/blob/develop/include/boost/python/detail/... is wrong ?

You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless you have a specific reason not to do so.

Yes, but I think the error is because it doesn't understand the C++11 type alias. Better to use: typedef std::integral_constant true_; typedef std::integral_constant false_; According to MSDN, std::integral_constant was in Visual Studio 2008, which is Visual C++ 9.

Stefan Seefeld

4:16 p.m.

On 16.11.2017 10:21, Daniel James via Boost wrote:

...

On 16 November 2017 at 15:10, Peter Dimov via Boost wrote:

...
Stefan Seefeld wrote:

...
It looks like we falsely assume the compiler understands C++11 and thus use attempt to use std::integral_constant. Could it be that the conditional in https://github.com/boostorg/python/blob/develop/include/boost/python/detail/... is wrong ?

You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless you have a specific reason not to do so. Yes, but I think the error is because it doesn't understand the C++11 type alias. Better to use:

typedef std::integral_constant true_; typedef std::integral_constant false_;

According to MSDN, std::integral_constant was in Visual Studio 2008, which is Visual C++ 9.

OK, thanks. I have committed https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a... and will merge to master once the change cycles through a round of tests. (I have to admit that I find it extremely daunting to navigate the online test matrix. There are so many false positives that it's hard to spot actual failures.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Daniel James

4:33 p.m.

On 16 November 2017 at 16:16, Stefan Seefeld via Boost wrote:

...

OK, thanks. I have committed https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a... and will merge to master once the change cycles through a round of tests. (I have to admit that I find it extremely daunting to navigate the online test matrix. There are so many false positives that it's hard to spot actual failures.)

Presumably a lot of those are due to python not being available or properly set up, would it be possible to detect this in boost build?

Stefan Seefeld

4:48 p.m.

On 16.11.2017 11:33, Daniel James via Boost wrote:

...

...
OK, thanks. I have committed https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a... and will merge to master once the change cycles through a round of tests. (I have to admit that I find it extremely daunting to navigate the online test matrix. There are so many false positives that it's hard to spot actual failures.) Presumably a lot of those are due to python not being available or

On 16 November 2017 at 16:16, Stefan Seefeld via Boost wrote: properly set up, would it be possible to detect this in boost build?

Of course ! I agree, such situations should be flagged much earlier, and the Boost.Python build (and tests) skipped. Sometime however the failure is different, though, but with the same net effect: rendering the test results useless as the failures don't tell anything about the code, but rather the testing platform setup. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Stefan Seefeld

17 Nov 17 Nov

4:02 p.m.

On 16.11.2017 11:16, Stefan Seefeld wrote:

...

On 16.11.2017 10:21, Daniel James via Boost wrote:

...
On 16 November 2017 at 15:10, Peter Dimov via Boost wrote:

...
Stefan Seefeld wrote:

...
It looks like we falsely assume the compiler understands C++11 and thus use attempt to use std::integral_constant. Could it be that the conditional in https://github.com/boostorg/python/blob/develop/include/boost/python/detail/... is wrong ? You should probably be checking BOOST_NO_CXX11_HDR_TYPE_TRAITS there unless you have a specific reason not to do so. Yes, but I think the error is because it doesn't understand the C++11 type alias. Better to use:

typedef std::integral_constant true_; typedef std::integral_constant false_;

According to MSDN, std::integral_constant was in Visual Studio 2008, which is Visual C++ 9.

OK, thanks. I have committed https://github.com/boostorg/python/commit/b9d0d974995d2ed6a7aeed877ee4d8ab0a... and will merge to master once the change cycles through a round of tests. (I have to admit that I find it extremely daunting to navigate the online test matrix. There are so many false positives that it's hard to spot actual failures.)

So just for avoidance of doubt: at some point in the near future someone will send out a note to the list that the `master` branch is open for bug fixes, at which point this can be merged. Correct ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Daniel James

7:25 p.m.

On 17 November 2017 at 16:02, Stefan Seefeld via Boost wrote:

...

So just for avoidance of doubt: at some point in the near future someone will send out a note to the list that the `master` branch is open for bug fixes, at which point this can be merged. Correct ?

Yes, once the beta is out, master will be open fixes. Although you can merge this change now if you want, I'll include it if there's a second release candidate for the beta, otherwise it will be picked up when the commit bot is restarted on master.

Tom Kent

7:34 p.m.

On Fri, Nov 17, 2017 at 1:25 PM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

On 17 November 2017 at 16:02, Stefan Seefeld via Boost wrote:

...
So just for avoidance of doubt: at some point in the near future someone will send out a note to the list that the `master` branch is open for bug fixes, at which point this can be merged. Correct ?

Yes, once the beta is out, master will be open fixes. Although you can merge this change now if you want, I'll include it if there's a second release candidate for the beta, otherwise it will be picked up when the commit bot is restarted on master.

I had assumed that we were waiting for b1_rc2 for this fix, since it was identified as a clear breakage for one of the supported compilers. I'd personally like to see the releases (and also betas) at least build the libraries that need to be built across the >=msvc-10.0 compilers. Tom

Daniel James

10:56 p.m.

On 17 November 2017 at 19:34, Tom Kent via Boost wrote:

...

I had assumed that we were waiting for b1_rc2 for this fix, since it was identified as a clear breakage for one of the supported compilers. I'd personally like to see the releases (and also betas) at least build the libraries that need to be built across the >=msvc-10.0 compilers.

I don't think we've ever stated such a requirement for betas, but I don't know if there's going to be a second release candidate, I haven't even discussed it with the other release managers yet.

Tom Kent

18 Nov 18 Nov

1:08 a.m.

On Fri, Nov 17, 2017 at 4:56 PM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

On 17 November 2017 at 19:34, Tom Kent via Boost wrote:

...
I had assumed that we were waiting for b1_rc2 for this fix, since it was identified as a clear breakage for one of the supported compilers. I'd personally like to see the releases (and also betas) at least build

the

...
libraries that need to be built across the >=msvc-10.0 compilers.

I don't think we've ever stated such a requirement for betas, but I don't know if there's going to be a second release candidate, I haven't even discussed it with the other release managers yet.

I don't think there should be any stated requirement. I was just going with what I've seen in the past as a rule of thumb plus my general desire. Tom

Vinnie Falco

19 Nov 19 Nov

2:13 a.m.

I just pushed a tiny fix to the beast master branch: https://github.com/boostorg/beast/commit/73eba08cf4029d63f7830d1adef9787b49b... The bug is minor and likely will not be noticed so if this ends up being delayed to 1.67.0 that is okay. Thanks

Daniel James

12:19 p.m.

On 19 November 2017 at 02:13, Vinnie Falco via Boost wrote:

...

I just pushed a tiny fix to the beast master branch:

https://github.com/boostorg/beast/commit/73eba08cf4029d63f7830d1adef9787b49b...

The bug is minor and likely will not be noticed so if this ends up being delayed to 1.67.0 that is okay.

You can fix bugs after the beta. But I'm making a second release candidate with the python fix, I'll include this as well. It'll be based on this commit: https://github.com/boostorg/boost/commit/81dcc8faaafafaff16c9fd1f676ecd13b3f... Unless anyone sees anything wrong with that?

Olaf van der Spek

16 Nov 16 Nov

3:26 p.m.

On Thu, Nov 16, 2017 at 11:39 AM, Daniel James 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.

PS C:\vc\boost> .\bootstrap.bat Building Boost.Build engine Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics. You can try to obtain a prebuilt binary from http://sf.net/project/showfiles.php?group_id=7586&package_id=72941 Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case. ********************************************************************** ** Visual Studio 2017 Developer Command Prompt v15.4.3 ** Copyright (c) 2017 Microsoft Corporation ********************************************************************** [vcvarsall.bat] Environment initialized for: 'x86' ### ### Using 'vc141' toolset. ### C:\Users\Olaf\source>if exist bootstrap rd /S /Q bootstrap C:\Users\Olaf\source>md bootstrap C:\Users\Olaf\source>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\yyacc0 yyacc.c yyacc.c c1: fatal error C1083: Cannot open source file: 'yyacc.c': No such file or directory -- Olaf

Mikhail Strelnikov

6:23 p.m.

This is Microsoft's bug, they should not change current directory in their vsdevcmd_end.bat. https://github.com/boostorg/build/pull/252 On Thu, Nov 16, 2017 at 6:26 PM, Olaf van der Spek via Boost wrote:

...

On Thu, Nov 16, 2017 at 11:39 AM, Daniel James 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.

PS C:\vc\boost> .\bootstrap.bat Building Boost.Build engine

Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case.

********************************************************************** ** Visual Studio 2017 Developer Command Prompt v15.4.3 ** Copyright (c) 2017 Microsoft Corporation ********************************************************************** [vcvarsall.bat] Environment initialized for: 'x86' ### ### Using 'vc141' toolset. ###

C:\Users\Olaf\source>if exist bootstrap rd /S /Q bootstrap

C:\Users\Olaf\source>md bootstrap

C:\Users\Olaf\source>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\yyacc0 yyacc.c yyacc.c c1: fatal error C1083: Cannot open source file: 'yyacc.c': No such file or directory

-- Olaf

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

Daniel James

17 Nov 17 Nov

9:30 a.m.

On 16 November 2017 at 18:23, Mikhail Strelnikov via Boost wrote:

...

This is Microsoft's bug, they should not change current directory in their vsdevcmd_end.bat.

https://github.com/boostorg/build/pull/252

It looks like there's an incoming workaround: https://github.com/boostorg/build/pull/263 I'd rather not delay this beta for this, as it's an issue with a preview compiler, but hopefully it should be fixed soon.

Olaf van der Spek

9:59 a.m.

On Fri, Nov 17, 2017 at 10:30 AM, Daniel James via Boost wrote:

...

On 16 November 2017 at 18:23, Mikhail Strelnikov via Boost wrote:

...
This is Microsoft's bug, they should not change current directory in their vsdevcmd_end.bat.

https://github.com/boostorg/build/pull/252

It looks like there's an incoming workaround:

https://github.com/boostorg/build/pull/263

I'd rather not delay this beta for this, as it's an issue with a preview compiler, but hopefully it should be fixed soon.

15.4 is not preview.. -- Olaf

Olaf van der Spek

16 Nov 16 Nov

3:37 p.m.

On Thu, Nov 16, 2017 at 11:39 AM, Daniel James 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.

MSVC 15.5.0 preview 4: 1>Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message. 1>c:\vc\boost\boost\asio\detail\type_traits.hpp(57): error C4996: 'std::result_of': warning STL4014: std::result_of and std::result_of_t are deprecated in C++17. They are superseded by std::invoke_result and std::invoke_result_t. You can define _SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. 1>c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.12.25827\include\type_traits(1807): note: see declaration of 'std::result_of' 1>c:\vc\boost\boost\asio\associated_allocator.hpp(103): error C4996: 'std::allocator<void>': warning STL4009: std::allocator<void> is deprecated in C++17. You can define _SILENCE_CXX17_ALLOCATOR_VOID_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. 1>c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.12.25827\include\xmemory0(1087): note: see declaration of 'std::allocator<void>' 1>c:\vc\boost\boost\asio\use_future.hpp(130): error C4996: 'std::allocator<void>': warning STL4009: std::allocator<void> is deprecated in C++17. You can define _SILENCE_CXX17_ALLOCATOR_VOID_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. 1>c:\program files (x86)\microsoft visual studio\preview\community\vc\tools\msvc\14.12.25827\include\xmemory0(1087): note: see declaration of 'std::allocator<void>' 1>Done building project "Polylines.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== -- Olaf

Marcel Raad

3:55 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James via Boost Sent: Donnerstag, 16. November 2017 11:39 To: boost@lists.boost.org Cc: Daniel James Subject: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1

The release candidates for the 1.66.0 beta 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.

A first smoke test building one big project worked fine for me with VS 15.4.4. Only the annoying errors because I forgot to delete %TEMP%\ b2_msvc_*.cmd again: https://github.com/boostorg/build/issues/257 Marcel

Olaf van der Spek

4:05 p.m.

On Thu, Nov 16, 2017 at 4:55 PM, Marcel Raad via Boost wrote:

...

A first smoke test building one big project worked fine for me with VS 15.4.4.

Has 15.4.4 been released yet? -- Olaf

Marcel Raad

4:09 p.m.

...

-----Original Message----- From: Olaf van der Spek [mailto:ml@vdspek.org] Sent: Donnerstag, 16. November 2017 17:06 To: boost@lists.boost.org Cc: Marcel Raad Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1

On Thu, Nov 16, 2017 at 4:55 PM, Marcel Raad via Boost wrote:

...
A first smoke test building one big project worked fine for me with VS 15.4.4.

Has 15.4.4 been released yet?

Yes, I updated yesterday morning. Marcel

Marcel Raad

9:42 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcel Raad via Boost Sent: Donnerstag, 16. November 2017 16:55 To: boost@lists.boost.org Cc: Marcel Raad Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1

A first smoke test building one big project worked fine for me with VS 15.4.4.

This project obviously didn't use Asio. There are breaking changes in the "Initial merge of Networking TS compatibility." commit, which should probably at least be mentioned in Asio's changelog? The changelog is older than that commit, unfortunately. Also, ScopeExit still doesn't work with MSVC's /permissive- (ISO C++ compatibility mode), for which there is a PR: https://github.com/boostorg/scope_exit/pull/3 Marcel

Vinnie Falco

10:03 p.m.

On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost wrote:

...

There are breaking changes in the "Initial merge of Networking TS compatibility." commit

I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for the new Boost.Asio implementation) do you have any specific questions about the changes that I might be able to answer? Thanks

Marcel Raad

17 Nov 17 Nov

9:06 a.m.

Hi Vinnie,

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinnie Falco via Boost Sent: Donnerstag, 16. November 2017 23:04 To: boost@lists.boost.org Cc: Vinnie Falco Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1

On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost wrote:

...
There are breaking changes in the "Initial merge of Networking TS compatibility." commit

I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for the new Boost.Asio implementation) do you have any specific questions about the changes that I might be able to answer?

thanks for the offer! All issues are sorted out now: - we were still using the deprecated asio::strand typedef as there were no warnings - we were reyling on implicit io_service.hpp includes - strand::wrap lost support for more than two function arguments as detail::binder[3..5] were removed. Chris Kohlhoff just responded to me privately that he'll add them back. Thanks, Marcel

Daniel James

9:50 a.m.

On 16 November 2017 at 22:03, Vinnie Falco via Boost wrote:

...

On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost wrote:

...
There are breaking changes in the "Initial merge of Networking TS compatibility." commit

I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for the new Boost.Asio implementation) do you have any specific questions about the changes that I might be able to answer?

It's be useful if someone wrote some release notes. It doesn't have to be the maintainer.

Andrey Semashev

10:38 a.m.

On 11/17/17 12:50, Daniel James via Boost wrote:

...

On 16 November 2017 at 22:03, Vinnie Falco via Boost wrote:

...
On Thu, Nov 16, 2017 at 1:42 PM, Marcel Raad via Boost wrote:

...
There are breaking changes in the "Initial merge of Networking TS compatibility." commit

I updated Beast to use the "Net.TS-flavored Boost.Asio" (my name for the new Boost.Asio implementation) do you have any specific questions about the changes that I might be able to answer?

It's be useful if someone wrote some release notes. It doesn't have to be the maintainer.

It looks like Boost.ASIO is based on some pre-release version of ASIO 1.11.0, which has release notes here: http://think-async.com/asio/asio-1.11.0/doc/asio/history.html#asio.history.a... Unfortunately, it looks like some of the new features are not available in Boost.ASIO (e.g. I couldn't find address_cast<>). It looks like Christopher is the only one who knows what changes went into Boost, unless someone else follows the development closely. I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file: https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qb... Thanks.

Vinnie Falco

3:58 p.m.

On Fri, Nov 17, 2017 at 2:38 AM, Andrey Semashev via Boost wrote:

...

I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO.

Note that there are a growing number of issues and pull requests in both of the asio repositories: https://github.com/boostorg/asio/issues https://github.com/boostorg/asio/pulls https://github.com/chriskohlhoff/asio/issues https://github.com/chriskohlhoff/asio/pulls In some cases it is affecting the quality of the Boost library, for example: https://github.com/chriskohlhoff/asio/issues/246 If there is anything that the rest of the Boost community can do to assist with unblocking, I would like to know - I am willing to help. Thanks

Christopher Kohlhoff

19 Nov 19 Nov

11:54 p.m.

...

On 17 Nov 2017, at 9:38 pm, Andrey Semashev wrote:

I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file:

https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qb...

Based on the calendar (i.e. http://www.boost.org/development/index.html) I had set aside some time to prepare the release notes prior to the actual 1.66 release in December. I have just now written some placeholder notes so that beta users will be aware that there have been some changes.

Daniel James

20 Nov 20 Nov

11:03 a.m.

On 19 November 2017 at 23:54, Christopher Kohlhoff via Boost wrote:

...

...
On 17 Nov 2017, at 9:38 pm, Andrey Semashev wrote:

I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file:

https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qb...

Based on the calendar (i.e. http://www.boost.org/development/index.html) I had set aside some time to prepare the release notes prior to the actual 1.66 release in December.

I have just now written some placeholder notes so that beta users will be aware that there have been some changes.

Thanks, it's useful to have something in the beta so that people can tell if what they needs to tested, and whether the release will affect them.

Andrey Semashev

6 Dec 6 Dec

2:20 p.m.

On 11/20/17 02:54, Christopher Kohlhoff wrote:

...

...
On 17 Nov 2017, at 9:38 pm, Andrey Semashev wrote:

I'm CCing Christopher in hope he will be able to provide some release notes for Boost.ASIO. For convenience, the release notes can be provided by creating a pull request for this file:

https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.qb...

Based on the calendar (i.e. http://www.boost.org/development/index.html) I had set aside some time to prepare the release notes prior to the actual 1.66 release in December.

I have just now written some placeholder notes so that beta users will be aware that there have been some changes.

Just a friendly reminder that the 1.66 release is near and the list of changes is still TBD.

Stefan Seefeld

8 Dec 8 Dec

12:10 p.m.

Hello, I'd like to report again an issue with the Windows binary packages that is still present with the 1.66.0 release (candidate). The issue is reported to the Boost.Python bug tracker at https://github.com/boostorg/python/issues/129, though I don't think I can address it there. In the Windows binary package the libboost_python3 library is built against (and links with) python2. I can't reproduce this myself when building Boost the normal way, and I don't know who owns the logic for building Windows binary packages. It doesn't seem to have its own repo / issue tracker. The fix might thus affect some piece of code that isn't itself part of the release. But it would be great if someone could look into it soon anyhow. :-) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Tom Kent

1:32 p.m.

On Fri, Dec 8, 2017 at 6:10 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...

Hello,

I'd like to report again an issue with the Windows binary packages that is still present with the 1.66.0 release (candidate). The issue is reported to the Boost.Python bug tracker at https://github.com/boostorg/python/issues/129, though I don't think I can address it there. In the Windows binary package the libboost_python3 library is built against (and links with) python2. I can't reproduce this myself when building Boost the normal way, and I don't know who owns the logic for building Windows binary packages. It doesn't seem to have its own repo / issue tracker. The fix might thus affect some piece of code that isn't itself part of the release. But it would be great if someone could look into it soon anyhow. :-)

I've got the logic for the windows builds here: https://github.com/teeks99/boost-release-windows/ I'm baffled by why this is happening. I'm including both python 2 and 3 paths in user-config.jam: https://github.com/teeks99/boost-release-windows/blob/master/user-config.jam... Is there anything else I should be doing for the python build? Tom

Stefan Seefeld

2:28 p.m.

On 08.12.2017 08:32, Tom Kent via Boost wrote:

...

On Fri, Dec 8, 2017 at 6:10 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...
Hello,

I'd like to report again an issue with the Windows binary packages that is still present with the 1.66.0 release (candidate). The issue is reported to the Boost.Python bug tracker at https://github.com/boostorg/python/issues/129, though I don't think I can address it there. In the Windows binary package the libboost_python3 library is built against (and links with) python2. I can't reproduce this myself when building Boost the normal way, and I don't know who owns the logic for building Windows binary packages. It doesn't seem to have its own repo / issue tracker. The fix might thus affect some piece of code that isn't itself part of the release. But it would be great if someone could look into it soon anyhow. :-)

I've got the logic for the windows builds here: https://github.com/teeks99/boost-release-windows/

I'm baffled by why this is happening. I'm including both python 2 and 3 paths in user-config.jam: https://github.com/teeks99/boost-release-windows/blob/master/user-config.jam...

Is there anything else I should be doing for the python build?

I managed to reproduce the problem on Linux (not quite the same, as on Linux Boost.Python isn't linked to the Python library, but the problem is there nonetheless). I reported my findings to https://lists.boost.org/boost-build/2017/12/29715.php. In a nutshell, the problem is that the Boost.Build logic doesn't create a build tree layout that contains the Python version as a path component. As a consequence, it mistakenly reuses object files compiled with the previous Python version when linking Boost.Python libraries for subsequent Python versions. The real fix (arguably to Boost.Build) is quite involved, and may be too late for the upcoming release. It might be better to consider changing the build script to invoke `b2` multiple times (once per Python version), and then package the libraries together, so the end result will look the same. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Tom Kent

9 Dec 9 Dec

2:32 a.m.

On Fri, Dec 8, 2017 at 8:28 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...

On 08.12.2017 08:32, Tom Kent via Boost wrote:

...
On Fri, Dec 8, 2017 at 6:10 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...
Hello,

I'd like to report again an issue with the Windows binary packages that is still present with the 1.66.0 release (candidate). The issue is reported to the Boost.Python bug tracker at https://github.com/boostorg/python/issues/129, though I don't think I can address it there. In the Windows binary package the libboost_python3 library is built against (and links with) python2. I can't reproduce this myself when building Boost the normal way, and I don't know who owns the logic for building Windows binary packages. It doesn't seem to have its own repo / issue tracker. The fix might thus affect some piece of code that isn't itself part of the release. But it would be great if someone could look into it soon anyhow. :-)

I've got the logic for the windows builds here: https://github.com/teeks99/boost-release-windows/

I'm baffled by why this is happening. I'm including both python 2 and 3 paths in user-config.jam: https://github.com/teeks99/boost-release-windows/blob/master /user-config.jam.template

Is there anything else I should be doing for the python build?

I managed to reproduce the problem on Linux (not quite the same, as on Linux Boost.Python isn't linked to the Python library, but the problem is there nonetheless). I reported my findings to https://lists.boost.org/boost-build/2017/12/29715.php. In a nutshell, the problem is that the Boost.Build logic doesn't create a build tree layout that contains the Python version as a path component. As a consequence, it mistakenly reuses object files compiled with the previous Python version when linking Boost.Python libraries for subsequent Python versions.

The real fix (arguably to Boost.Build) is quite involved, and may be too late for the upcoming release. It might be better to consider changing the build script to invoke `b2` multiple times (once per Python version), and then package the libraries together, so the end result will look the same.

That sounds tricky. Does that mean that I'd need to modify my user-config.jam file between the two builds? (I.e. only have one version of python in there at a time?) I'm not sure I have the time to put in script changes for this before the next release. Instead, I think I'll just disable python3 (i.e. remove it from user-config.jam) so the windows build will only support python2. It is kinda a toss-up as to py2 vs. py3, the python community is definitely shifting away from py2 (end of life in 2020), but if there are users who have been building with the windows builds in the past, it was only working for py2 so I don't want to break that. Tom

Stefan Seefeld

2:36 a.m.

On 08.12.2017 21:32, Tom Kent via Boost wrote:

...

On Fri, Dec 8, 2017 at 8:28 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...
On 08.12.2017 08:32, Tom Kent via Boost wrote:

...
On Fri, Dec 8, 2017 at 6:10 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

...
Hello,

I'd like to report again an issue with the Windows binary packages that is still present with the 1.66.0 release (candidate). The issue is reported to the Boost.Python bug tracker at https://github.com/boostorg/python/issues/129, though I don't think I can address it there. In the Windows binary package the libboost_python3 library is built against (and links with) python2. I can't reproduce this myself when building Boost the normal way, and I don't know who owns the logic for building Windows binary packages. It doesn't seem to have its own repo / issue tracker. The fix might thus affect some piece of code that isn't itself part of the release. But it would be great if someone could look into it soon anyhow. :-)

I've got the logic for the windows builds here: https://github.com/teeks99/boost-release-windows/

I'm baffled by why this is happening. I'm including both python 2 and 3 paths in user-config.jam: https://github.com/teeks99/boost-release-windows/blob/master /user-config.jam.template Is there anything else I should be doing for the python build? I managed to reproduce the problem on Linux (not quite the same, as on Linux Boost.Python isn't linked to the Python library, but the problem is there nonetheless). I reported my findings to https://lists.boost.org/boost-build/2017/12/29715.php. In a nutshell, the problem is that the Boost.Build logic doesn't create a build tree layout that contains the Python version as a path component. As a consequence, it mistakenly reuses object files compiled with the previous Python version when linking Boost.Python libraries for subsequent Python versions.

The real fix (arguably to Boost.Build) is quite involved, and may be too late for the upcoming release. It might be better to consider changing the build script to invoke `b2` multiple times (once per Python version), and then package the libraries together, so the end result will look the same.

That sounds tricky.

Does that mean that I'd need to modify my user-config.jam file between the two builds? (I.e. only have one version of python in there at a time?)

I believe so, yes (though would prefer someone like Steven or Rene as the real experts to confirm the whole issue, as I may miss something).

...

I'm not sure I have the time to put in script changes for this before the next release. Instead, I think I'll just disable python3 (i.e. remove it from user-config.jam) so the windows build will only support python2. It is kinda a toss-up as to py2 vs. py3, the python community is definitely shifting away from py2 (end of life in 2020), but if there are users who have been building with the windows builds in the past, it was only working for py2 so I don't want to break that.

Right, I agree with that assessment & strategy. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Steven Watanabe

2:52 a.m.

AMDG On 12/08/2017 07:36 PM, Stefan Seefeld via Boost wrote:

...

On 08.12.2017 21:32, Tom Kent via Boost wrote:

...
That sounds tricky.

Does that mean that I'd need to modify my user-config.jam file between the two builds? (I.e. only have one version of python in there at a time?)

I believe so, yes (though would prefer someone like Steven or Rene as the real experts to confirm the whole issue, as I may miss something).

I'm not really familiar with the python toolset, but user-config.jam can contain arbitrary code, so, if there isn't a better solution, you can fall back on something like this: # Adjust the build paths when python3 is in use. # Note: This applies to all targets, even those # unrelated to python, so it's probably a bad idea # to use the --use-python3 option for building anything # other than Boost.Python. import feature ; feature.feature python-version : 3 : propagated optional ; import modules ; import toolset ; # Allow command line switching if --use-python3 in [ modules.peek : ARGV ] { project : requirements <python-version>3 ; using python : 3.xx : ... ; } else { using python : 2.xx : ... ; } In Christ, Steven Watanabe

Stefan Seefeld

3 a.m.

Hi Steven, On 08.12.2017 21:52, Steven Watanabe via Boost wrote:

...

AMDG

On 12/08/2017 07:36 PM, Stefan Seefeld via Boost wrote:

...
...
That sounds tricky.

Does that mean that I'd need to modify my user-config.jam file between the two builds? (I.e. only have one version of python in there at a time?) I believe so, yes (though would prefer someone like Steven or Rene as

On 08.12.2017 21:32, Tom Kent via Boost wrote: the real experts to confirm the whole issue, as I may miss something).

I'm not really familiar with the python toolset, but user-config.jam can contain arbitrary code, so, if there isn't a better solution, you can fall back on something like this:

# Adjust the build paths when python3 is in use. # Note: This applies to all targets, even those # unrelated to python, so it's probably a bad idea # to use the --use-python3 option for building anything # other than Boost.Python. import feature ; feature.feature python-version : 3 : propagated optional ;

import modules ; import toolset ; # Allow command line switching if --use-python3 in [ modules.peek : ARGV ] { project : requirements <python-version>3 ; using python : 3.xx : ... ; } else { using python : 2.xx : ... ; }

Can you elaborate a bit on what this will achieve ? It seems this simply means the same user-config.jam file can be reused for two `b2` invocations (one with `--use-python3` and one without). But the build logic would still need to be augmented to: 1) run `b2` as before 2) remove the build tree for Boost.Python, i.e. everything under `bin.v2/libs/python` 3) rerun `b2`, this time with additional `--use-python3 --with-python` arguments, to only rebuild Boost.Python, this time with Python3. 4) collect all binaries from the staging area during packaging. Correct ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

Steven Watanabe

3:12 a.m.

AMDG On 12/08/2017 08:00 PM, Stefan Seefeld via Boost wrote:

...

On 08.12.2017 21:52, Steven Watanabe via Boost wrote:

...
<snip> import feature ; feature.feature python-version : 3 : propagated optional ;

import modules ; import toolset ; # Allow command line switching if --use-python3 in [ modules.peek : ARGV ] { project : requirements <python-version>3 ; using python : 3.xx : ... ; } else { using python : 2.xx : ... ; }

Can you elaborate a bit on what this will achieve ? It seems this simply means the same user-config.jam file can be reused for two `b2` invocations (one with `--use-python3` and one without). But the build logic would still need to be augmented to:

1) run `b2` as before 2) remove the build tree for Boost.Python, i.e. everything under `bin.v2/libs/python` 3) rerun `b2`, this time with additional `--use-python3 --with-python` arguments, to only rebuild Boost.Python, this time with Python3. 4) collect all binaries from the staging area during packaging.

Correct ?

Step (2) is not necessary. python-version is specifically to avoid this step, by forcing the python3 build to use a different build directory. In Christ, Steven Watanabe

Stefan Seefeld

3:18 a.m.

On 08.12.2017 22:12, Steven Watanabe via Boost wrote:

...

AMDG

On 12/08/2017 08:00 PM, Stefan Seefeld via Boost wrote:

...
On 08.12.2017 21:52, Steven Watanabe via Boost wrote:

...
<snip> import feature ; feature.feature python-version : 3 : propagated optional ;

import modules ; import toolset ; # Allow command line switching if --use-python3 in [ modules.peek : ARGV ] { project : requirements <python-version>3 ; using python : 3.xx : ... ; } else { using python : 2.xx : ... ; } Can you elaborate a bit on what this will achieve ? It seems this simply means the same user-config.jam file can be reused for two `b2` invocations (one with `--use-python3` and one without). But the build logic would still need to be augmented to:

1) run `b2` as before 2) remove the build tree for Boost.Python, i.e. everything under `bin.v2/libs/python` 3) rerun `b2`, this time with additional `--use-python3 --with-python` arguments, to only rebuild Boost.Python, this time with Python3. 4) collect all binaries from the staging area during packaging.

Correct ?

Step (2) is not necessary. python-version is specifically to avoid this step, by forcing the python3 build to use a different build directory.

I see, thanks. What would be the "correct" fix for this, i.e. where would this `python-version` feature have to be defined (and used) to allow `b2` to be usable as intended, i.e. building for both, Python2 and Python3 in a single run ? (I take it even with this it would still not be possible to build against two arbitrary Python versions, as the feature as it is defined now will only distinguish between '2' and '3', rather than taking the exact Python version into account, as it does for toolchain versions.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

Steven Watanabe

3:40 a.m.

AMDG On 12/08/2017 08:18 PM, Stefan Seefeld via Boost wrote:

...

I see, thanks. What would be the "correct" fix for this, i.e. where would this `python-version` feature have to be defined (and used) to allow `b2` to be usable as intended, i.e. building for both, Python2 and Python3 in a single run ?

The right place is either build/src/tools/python.jam or the Boost.Python Jamfile. Hmm. It looks like there's already code to handle this (<python>). I wonder why it doesn't work.

...

(I take it even with this it would still not be possible to build against two arbitrary Python versions, as the feature as it is defined now will only distinguish between '2' and '3', rather than taking the exact Python version into account, as it does for toolchain versions.)

This is just a quick hack. The version could be any string. The library names also need to be mangled. If I remember correctly, the current Jamfile only distinguishes boost_python and boost_python3. In Christ, Steven Watanabe

Stefan Seefeld

4:03 a.m.

On 08.12.2017 22:40, Steven Watanabe via Boost wrote:

...

AMDG

On 12/08/2017 08:18 PM, Stefan Seefeld via Boost wrote:

...
I see, thanks. What would be the "correct" fix for this, i.e. where would this `python-version` feature have to be defined (and used) to allow `b2` to be usable as intended, i.e. building for both, Python2 and Python3 in a single run ? The right place is either build/src/tools/python.jam or the Boost.Python Jamfile. Hmm. It looks like there's already code to handle this (<python>). I wonder why it doesn't work.

I have submitted https://github.com/boostorg/build/issues/271 for this. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2544

Age (days ago)

2567

Last active (days ago)

List overview

Download

42 comments

11 participants

participants (11)

Andrey Semashev
Christopher Kohlhoff
Daniel James
Marcel Raad
Mikhail Strelnikov
Olaf van der Spek
Peter Dimov
Stefan Seefeld
Steven Watanabe
Tom Kent
Vinnie Falco