[release] Boost 1.70.0 Beta 1 Release Candidate 3
A new release candidates for the first 1.70.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/ Changes since RC2: * Relative paths for --prefix, --libdir, etc. are now bound relative to the current working directory, instead of being relative to the Jamfile. Thanks to Tom Kent for the report, and Steven and Peter for the fixes. Changes since RC1: * The Jamfile for Boost.Predef has been updated to allow running the tests from /status. Thanks to mike.dev@gmx.de for the report, and to Rene for the fix. The release notes are not yet available. The SHA256 checksums are as follows: dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1_rc3.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1_rc3.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1_rc3.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1_rc3.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
On Mon, Mar 11, 2019 at 10:40 AM Marshall Clow
A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/
Changes since RC2: * Relative paths for --prefix, --libdir, etc. are now bound relative to the current working directory, instead of being relative to the Jamfile. Thanks to Tom Kent for the report, and Steven and Peter for the fixes.
Changes since RC1: * The Jamfile for Boost.Predef has been updated to allow running the tests from /status. Thanks to mike.dev@gmx.de for the report, and to Rene for the fix.
The release notes are not yet available.
The SHA256 checksums are as follows:
dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1_rc3.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1_rc3.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1_rc3.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1_rc3.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 got tired of the 'register' warnings in the python headers, and added '-Wno-register' to my user-config.jam. Given that, I have successfully built this with the following configurations. Mac OS X 10.14.3 with Apple LLVM version 10.0.0 (clang-1000.10.44.4): Successful build with C++03/11/14/17/2a Mac OS X 10.11.6 with Apple LLVM version 8.0.0 Successful build with C++03/11/14/1z Mac OS X 10.11.6 with clang built from trunk: Successful build with C++03/11/14/17/2a Ubuntu 18.04 with gcc 7.3.2: Successful build with C++03/11/14/17 Ubuntu 18.04 with clang built from trunk: Successful build with C++03/11/14/17/2a -- Marshall
On Mon, Mar 11, 2019 at 2:27 PM Marshall Clow
On Mon, Mar 11, 2019 at 10:40 AM Marshall Clow
wrote: A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/
Changes since RC2: * Relative paths for --prefix, --libdir, etc. are now bound relative to the current working directory, instead of being relative to the Jamfile. Thanks to Tom Kent for the report, and Steven and Peter for the fixes.
Changes since RC1: * The Jamfile for Boost.Predef has been updated to allow running the tests from /status. Thanks to mike.dev@gmx.de for the report, and to Rene for the fix.
The release notes are not yet available.
The SHA256 checksums are as follows:
dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1_rc3.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1_rc3.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1_rc3.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1_rc3.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 got tired of the 'register' warnings in the python headers, and added '-Wno-register' to my user-config.jam. Given that, I have successfully built this with the following configurations.
Mac OS X 10.14.3 with Apple LLVM version 10.0.0 (clang-1000.10.44.4): Successful build with C++03/11/14/17/2a
Mac OS X 10.11.6 with Apple LLVM version 8.0.0 Successful build with C++03/11/14/1z
Mac OS X 10.11.6 with clang built from trunk: Successful build with C++03/11/14/17/2a
This should have been Mac OS 10.14.3. Sorry. c++17/2a do not build on Mac OS 10.11 with clang trunk due to the lack of std::uncaught_exceptions.
Ubuntu 18.04 with gcc 7.3.2: Successful build with C++03/11/14/17
Ubuntu 18.04 with clang built from trunk: Successful build with C++03/11/14/17/2a
Looks good building (Visual Studio 10-14.1) with `--prefix=..... install`, I get bzip2 and zlib binaries. I still don't get the bzip2 and zlib binaries when using `stage`. 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. Full build logs are at: https://gist.github.com/teeks99/221bec5d16859ce1db064d89574933d4 Tom On Mon, Mar 11, 2019 at 12:40 PM Marshall Clow via Boost-users < boost-users@lists.boost.org> wrote:
A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/
Changes since RC2: * Relative paths for --prefix, --libdir, etc. are now bound relative to the current working directory, instead of being relative to the Jamfile. Thanks to Tom Kent for the report, and Steven and Peter for the fixes.
Changes since RC1: * The Jamfile for Boost.Predef has been updated to allow running the tests from /status. Thanks to mike.dev@gmx.de for the report, and to Rene for the fix.
The release notes are not yet available.
The SHA256 checksums are as follows:
dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1_rc3.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1_rc3.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1_rc3.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1_rc3.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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Tom Kent wrote:
I still don't get the bzip2 and zlib binaries when using `stage`.
Hi Tom, I tried to reproduce this, by downloading RC3 and then D:\boost_1_70_0>set ZLIB_SOURCE=C:\projects\zlib-1.2.11 D:\boost_1_70_0>set BZIP2_SOURCE=C:\projects\bzip2-1.0.6 D:\boost_1_70_0>b2 -j8 --with-iostreams --build-type=complete toolset=msvc-10.0 address-model=32 architecture=x86 stage (following as closely as possible the lines in your gist and your previous description of your build process.) I do get bzip2 and zlib binaries in stage/lib: D:\boost_1_70_0>dir /b stage\lib boost_bzip2-vc100-mt-gd-x32-1_70.dll boost_bzip2-vc100-mt-gd-x32-1_70.lib boost_bzip2-vc100-mt-x32-1_70.dll boost_bzip2-vc100-mt-x32-1_70.lib boost_iostreams-vc100-mt-gd-x32-1_70.dll boost_iostreams-vc100-mt-gd-x32-1_70.lib boost_iostreams-vc100-mt-x32-1_70.dll boost_iostreams-vc100-mt-x32-1_70.lib boost_zlib-vc100-mt-gd-x32-1_70.dll boost_zlib-vc100-mt-gd-x32-1_70.lib boost_zlib-vc100-mt-x32-1_70.dll boost_zlib-vc100-mt-x32-1_70.lib libboost_bzip2-vc100-mt-gd-x32-1_70.lib libboost_bzip2-vc100-mt-s-x32-1_70.lib libboost_bzip2-vc100-mt-sgd-x32-1_70.lib libboost_bzip2-vc100-mt-x32-1_70.lib libboost_iostreams-vc100-mt-gd-x32-1_70.lib libboost_iostreams-vc100-mt-s-x32-1_70.lib libboost_iostreams-vc100-mt-sgd-x32-1_70.lib libboost_iostreams-vc100-mt-x32-1_70.lib libboost_zlib-vc100-mt-gd-x32-1_70.lib libboost_zlib-vc100-mt-s-x32-1_70.lib libboost_zlib-vc100-mt-sgd-x32-1_70.lib libboost_zlib-vc100-mt-x32-1_70.lib
Nevermind, that was my mistake. I'm not sure what I was looking at when I
missed seeing them, but they are in the archive I built with "stage", so I
was clearly wrong.
Thanks for checking that out,
Tom
On Mon, Mar 11, 2019 at 8:30 PM Peter Dimov via Boost
Tom Kent wrote:
I still don't get the bzip2 and zlib binaries when using `stage`.
Hi Tom,
I tried to reproduce this, by downloading RC3 and then
D:\boost_1_70_0>set ZLIB_SOURCE=C:\projects\zlib-1.2.11
D:\boost_1_70_0>set BZIP2_SOURCE=C:\projects\bzip2-1.0.6
D:\boost_1_70_0>b2 -j8 --with-iostreams --build-type=complete toolset=msvc-10.0 address-model=32 architecture=x86 stage
(following as closely as possible the lines in your gist and your previous description of your build process.)
I do get bzip2 and zlib binaries in stage/lib:
D:\boost_1_70_0>dir /b stage\lib boost_bzip2-vc100-mt-gd-x32-1_70.dll boost_bzip2-vc100-mt-gd-x32-1_70.lib boost_bzip2-vc100-mt-x32-1_70.dll boost_bzip2-vc100-mt-x32-1_70.lib boost_iostreams-vc100-mt-gd-x32-1_70.dll boost_iostreams-vc100-mt-gd-x32-1_70.lib boost_iostreams-vc100-mt-x32-1_70.dll boost_iostreams-vc100-mt-x32-1_70.lib boost_zlib-vc100-mt-gd-x32-1_70.dll boost_zlib-vc100-mt-gd-x32-1_70.lib boost_zlib-vc100-mt-x32-1_70.dll boost_zlib-vc100-mt-x32-1_70.lib libboost_bzip2-vc100-mt-gd-x32-1_70.lib libboost_bzip2-vc100-mt-s-x32-1_70.lib libboost_bzip2-vc100-mt-sgd-x32-1_70.lib libboost_bzip2-vc100-mt-x32-1_70.lib libboost_iostreams-vc100-mt-gd-x32-1_70.lib libboost_iostreams-vc100-mt-s-x32-1_70.lib libboost_iostreams-vc100-mt-sgd-x32-1_70.lib libboost_iostreams-vc100-mt-x32-1_70.lib libboost_zlib-vc100-mt-gd-x32-1_70.lib libboost_zlib-vc100-mt-s-x32-1_70.lib libboost_zlib-vc100-mt-sgd-x32-1_70.lib libboost_zlib-vc100-mt-x32-1_70.lib
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Marshall Clow wrote:
A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/
``` Bootstrapping is done. To build, run: .\b2 To generate header files, run: .\b2 headers ``` Ugh, I thought I fixed this. There's no need to generate header files from a release. And I had, but forgot to merge to master: https://github.com/boostorg/boost/commit/73410010da498717461a755dbeae3ab7daa... Not that anyone pays much attention to the bootstrap.bat output. :-)
On 3/11/19 6:40 PM, Marshall Clow via Boost wrote:
A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/
I've noticed that the symlinks are a little crazy in the 1.70.0 version. libboost_thread.so -> libboost_thread.so.1.70.0 libboost_thread.so.1 -> libboost_thread.so.1.70.0 libboost_thread.so.1.70 -> libboost_thread.so.1.70.0 libboost_thread.so.1.70.0 but soname is libboost_thread.so.1.70.0 Where are there the .1 and .1.70? There should only be the .so and the .so.1.70.0 Thank you for the cmake files :D - Adam
On 2019-03-12 9:04 a.m., Adam Majer via Boost wrote:
On 3/11/19 6:40 PM, Marshall Clow via Boost wrote:
A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc3/source/
I've noticed that the symlinks are a little crazy in the 1.70.0 version.
libboost_thread.so -> libboost_thread.so.1.70.0 libboost_thread.so.1 -> libboost_thread.so.1.70.0 libboost_thread.so.1.70 -> libboost_thread.so.1.70.0 libboost_thread.so.1.70.0
but soname is libboost_thread.so.1.70.0
Where are there the .1 and .1.70? There should only be the .so and the .so.1.70.0
Yeah, this whole versioning business makes absolutely no sense with Boost which has never cared for ABI compatibility. Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (5)
-
Adam Majer
-
Marshall Clow
-
Peter Dimov
-
stefan
-
Tom Kent