On Fri, Mar 8, 2019 at 8:57 PM Tom Kent wrote:

On Fri, Mar 8, 2019 at 6:42 PM Marshall Clow via Boost-users < boost-users@lists.boost.org> wrote:

...

On Fri, Mar 8, 2019 at 10:21 AM Marshall Clow wrote:

...

The release candidates for the first 1.70.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.70.0.beta.1.rc1/source/

The release notes are not yet available.

The SHA256 checksums are as follows:

a7c570d6307d05dc8d45a3b4c69a0afdcba2b22eac0c4da4d496559f53db7b89 ./boost_1_70_0_b1_rc1.7z 4b91b9a203cf12f6001cf39de83c7cc005fbc5390e2b4b2fc29ce7b19c0537a7 ./boost_1_70_0_b1_rc1.tar.bz2 460dd6499bba9df04c6bfa219b26097bad803b8758304ba45f2fc291aa42c96e ./boost_1_70_0_b1_rc1.tar.gz f209c9a086ed2c7882a0bc8755792f436eb141eaeb8c823ed57295ca9ce25b93 ./boost_1_70_0_b1_rc1.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

I'm having a problem with B2 in this release.

For many releases now, I have run a command such as: b2 -j16 --build-type=complete toolset=msvc-10.0 address-model=64 architecture=x86 --prefix="./" --libdir=lib32-msvc-10.0 --includedir=temp_inc install

to get the windows builds of each toolset. For the install, I set the prefix as the current directory, so that I'll get a lib{arch}-msvc-{ver} directory for each toolset in there. However, with this 1.70 release, it seems to ignore my prefix and put the headers in libs/headers/build/temp_inc/boost-1_70/boost, instead of temp_inc/boost-1_70/boost. For the libraries, it scattered them throughout the build in directories such as libs/coroutine/build/lib32-msvc-10.0/.

Any thoughts on what might be causing this? Am I using the --prefix --libdir and --inlcudedir correctly? Or at least not badly enough to warrant this?

Also, even though I have BZIP2_SOURCE and ZLIB_SOURCE set, I'm not seeing the appropriate bzip2 and zlib libraries being generated. Tom

On Fri, Mar 8, 2019 at 6:42 PM Marshall Clow via Boost-users < boost-users@lists.boost.org> wrote:

On Fri, Mar 8, 2019 at 10:21 AM Marshall Clow wrote:

...

The release candidates for the first 1.70.0 beta release are now available at:

https://dl.bintray.com/boostorg/beta/1.70.0.beta.1.rc1/source/

The release notes are not yet available.

The SHA256 checksums are as follows:

a7c570d6307d05dc8d45a3b4c69a0afdcba2b22eac0c4da4d496559f53db7b89 ./boost_1_70_0_b1_rc1.7z 4b91b9a203cf12f6001cf39de83c7cc005fbc5390e2b4b2fc29ce7b19c0537a7 ./boost_1_70_0_b1_rc1.tar.bz2 460dd6499bba9df04c6bfa219b26097bad803b8758304ba45f2fc291aa42c96e ./boost_1_70_0_b1_rc1.tar.gz f209c9a086ed2c7882a0bc8755792f436eb141eaeb8c823ed57295ca9ce25b93 ./boost_1_70_0_b1_rc1.zip

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

I have built the RC on Mac OS X 10.11 using Apple LLVM version 8.0.0 (clang-800.0.42.1) successfully while specifying c++03/11/14/1z

I have built the RC on Mac OS X 10.14 using Apple LLVM version 10.0.0 (clang-1000.10.44.4) successfully while specifying c++03/11/14, but failed when specifying c++17/2a, because the Python 2.7 headers shipped with Mac OS 10.14 use the "register" keyword:

In file included from /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85: /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:534:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] register PyObject *obj, /* Object */ ^~~~~~~~~

I have built the RC on Mac OS X 10.14 using a recent trunk build of clang (version 9.0.0 (https://github.com/llvm/llvm-project.git 881e83d8b94f1997de674ed8ff382a73a29a719d)) successfully while specifying c++03/11/14, but failed when specifying c++17/2a, because the Python 2.7 headers shipped with Mac OS 10.13 use the "register" keyword:

In file included from /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85: /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:534:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] register PyObject *obj, /* Object */ ^~~~~~~~~

(same results as with Apple's clang)

I have built the RC on Ubuntu 18.14 with gcc 7.3.2 successfully while specifying c++03/11/14, but failed when specifying c++17/2a, because the Python 2.7 headers shipped with 18.04 use the "register" keyword:

In file included from /usr/include/python2.7/Python.h:88: /usr/include/python2.7/unicodeobject.h:534:5: warning: 'register' storage class specifier is deprecated and incompatible with C++17 [-Wdeprecated-register] register PyObject *obj, /* Object */ ^~~~~~~~~

and I had the same results with a recently built version of clang on Ubuntu (success on 03/11/14, but python failures with 17/2a)

I encountered similar issues when trying to build python with modern versions of visual studio. I ended up making the decision [1] that msvc-14.0 would build against python 3.x while earlier versions would remain on python 2.7. Since python 2.X is going end of life at the end of the year [2], I'm thinking that I'm going to drop windows builds with boost python for the older compilers after that point. You're obviously free to test against whatever config you like, just wanted to mention that. Tom [1] https://lists.boost.org/Archives/boost/2018/07/242443.php [2] https://pythonclock.org/