[Boost-users] [release] Boost 1.70.0 Beta 1 Release Candidate 1

4 views
Skip to first unread message

Marshall Clow via Boost-users

unread,
Mar 8, 2019, 1:21:55 PM3/8/19
to Boost users list, boost@lists.boost.org List, Marshall Clow
The release candidates for the first 1.70.0 beta release are now available at:


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.

-- The Boost Release Managers

Michael Powell via Boost-users

unread,
Mar 8, 2019, 2:18:32 PM3/8/19
to boost...@lists.boost.org, Michael Powell
On Fri, Mar 8, 2019 at 1:22 PM Marshall Clow via Boost-users
<boost...@lists.boost.org> wrote:
>
> The release candidates for the first 1.70.0 beta release are now available at:

Nice work. Now that Boost is into the 70th minor of the 1st major
release... Not to sound critical, but does the major ever bump?
> _______________________________________________
> Boost-users mailing list
> Boost...@lists.boost.org
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Marshall Clow via Boost-users

unread,
Mar 8, 2019, 7:42:50 PM3/8/19
to Boost users list, boost@lists.boost.org List, Marshall Clow
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)

-- Marshall
 

Tom Kent via Boost-users

unread,
Mar 8, 2019, 10:17:01 PM3/8/19
to Boost users list, Tom Kent
On Fri, Mar 8, 2019 at 6:42 PM Marshall Clow via Boost-users <boost...@lists.boost.org> wrote:
On Fri, Mar 8, 2019 at 10:21 AM Marshall Clow <mclow...@gmail.com> wrote:
The release candidates for the first 1.70.0 beta release are now available at:


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?

Tom 

Tom Kent via Boost-users

unread,
Mar 8, 2019, 10:45:29 PM3/8/19
to Boost users list, Tom Kent
Also, even though I have BZIP2_SOURCE and ZLIB_SOURCE set, I'm not seeing the appropriate bzip2 and zlib libraries being generated.

Tom 

Tom Kent via Boost-users

unread,
Mar 9, 2019, 7:58:11 AM3/9/19
to Boost users list, Boost Developers List, Boost.Build developer's and user's list, Tom Kent
After updating my scripts to us "staging" instead of "install" to avoid the above issue, I was able to get everything else to build successfully for Visual Studio (msvc-10.0 through msvc-14.1, note this is the first release I haven't built against msvc-8.0 and 9.0). The only exception being the lack of bzip2 and zlib support mentioned above. 

toolset     arch    compile Link    Execute
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
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

Tom Kent via Boost-users

unread,
Mar 9, 2019, 8:14:33 AM3/9/19
to Boost users list, Tom Kent, boost@lists.boost.org List
On Fri, Mar 8, 2019 at 6:42 PM Marshall Clow via Boost-users <boost...@lists.boost.org> wrote:
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

Reply all
Reply to author
Forward
0 new messages