[release] Boost 1.68.0 Beta 1 Release Candidate 1
The release candidates for the first 1.68.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.68.0.beta.1.rc1/source/ The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: 4b39978aa227f56cc00715d48032e18f4bb259de756637a653b5acead4417e0b boost_1_68_0_b1_rc1.7z 39f6fdc16fc62041ca1401c5e8d1cd0220de24fd5d909eca3f0bf1049d1fd6f9 boost_1_68_0_b1_rc1.tar.bz2 9714d11a205e6f3a1cf1ed17b0caad8a64bc4a5459dfc6e1629e14e5e4b44dc7 boost_1_68_0_b1_rc1.tar.gz fe35f20eb5c2ebf5d4e4f15d0416e484058a732ca1a1e59b831b79d4d7702bdd boost_1_68_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
On Thu, Jul 5, 2018 at 7:55 PM, Marshall Clow
The release candidates for the first 1.68.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.68.0.beta.1.rc1/source/
The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ]
The SHA256 checksums are as follows:
4b39978aa227f56cc00715d48032e18f4bb259de756637a653b5acead4417e0b boost_1_68_0_b1_rc1.7z 39f6fdc16fc62041ca1401c5e8d1cd0220de24fd5d909eca3f0bf1049d1fd6f9 boost_1_68_0_b1_rc1.tar.bz2 9714d11a205e6f3a1cf1ed17b0caad8a64bc4a5459dfc6e1629e14e5e4b44dc7 boost_1_68_0_b1_rc1.tar.gz fe35f20eb5c2ebf5d4e4f15d0416e484058a732ca1a1e59b831b79d4d7702bdd boost_1_68_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 successfully built the rc1 release on Mac OS 10.11 with Apple clang 8.0 (c++03/c++11/c++14/c++1z) -- Marshall
On Thu, Jul 5, 2018 at 7:55 PM, Marshall Clow
The release candidates for the first 1.68.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.68.0.beta.1.rc1/source/
The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ]
The SHA256 checksums are as follows:
4b39978aa227f56cc00715d48032e18f4bb259de756637a653b5acead4417e0b boost_1_68_0_b1_rc1.7z 39f6fdc16fc62041ca1401c5e8d1cd0220de24fd5d909eca3f0bf1049d1fd6f9 boost_1_68_0_b1_rc1.tar.bz2 9714d11a205e6f3a1cf1ed17b0caad8a64bc4a5459dfc6e1629e14e5e4b44dc7 boost_1_68_0_b1_rc1.tar.gz fe35f20eb5c2ebf5d4e4f15d0416e484058a732ca1a1e59b831b79d4d7702bdd boost_1_68_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 successfully built the rc1 release on Mac OS 10.13 with Apple clang 9.1 (c++03/c++11/c++14/c++17/c++2a) -- Marshall
On Thu, Jul 5, 2018 at 9:55 PM, Marshall Clow via Boost < boost@lists.boost.org> wrote:
The release candidates for the first 1.68.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.68.0.beta.1.rc1/source/
The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ]
The SHA256 checksums are as follows:
4b39978aa227f56cc00715d48032e18f4bb259de756637a653b5acead4417e0b boost_1_68_0_b1_rc1.7z 39f6fdc16fc62041ca1401c5e8d1cd0220de24fd5d909eca3f0bf1049d1fd6f9 boost_1_68_0_b1_rc1.tar.bz2 9714d11a205e6f3a1cf1ed17b0caad8a64bc4a5459dfc6e1629e14e5e4b44dc7 boost_1_68_0_b1_rc1.tar.gz fe35f20eb5c2ebf5d4e4f15d0416e484058a732ca1a1e59b831b79d4d7702bdd boost_1_68_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.
- It looks like boost/version.hpp hasn't been updated for 1.68. It still
has two instances of "67" in it, which seem to be cause the auto-linking
features for visual studio to look for *-1_67.lib files, while the ones
generated are *-1_68.lib. This is present in all four archive formats.
Showstopper.
- Tests for Windows/Visual Studio builds failed for msvc-10.0 in program
options:
compile-c-c++
bin.v2\libs\program_options\build\msvc-10.0\debug\link-static\runtime-link-static\threading-multi\options_description.obj
options_description.cpp
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\utility(163)
: error C2440: 'initializing' : cannot convert from 'int' to 'const
std::basic_string<_Elem,_Traits,_Ax> '
with
[
_Elem=char,
_Traits=std::char_traits<char>,
_Ax=std::allocator<char>
]
Conversion from integral type to pointer type requires
reinterpret_cast, C-style cast or function-style cast
C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE\utility(247) : see reference to function template
instantiation 'std::_Pair_base<_Ty1,_Ty2>::_Pair_base<_Ty,_Ty>(_Other1
&&,_Other2 &&)' being compiled
with
[
_Ty1=const
std::basic_string
Will it be possible to build Boost 1.68.0 on Windows with Clang/LLVM? Thx....John Cary
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of JR Cary via Boost-users Sent: 06 July 2018 14:32 To: boost-users@lists.boost.org Cc: JR Cary Subject: [Boost-users] Boost 1.68.0, clang, windows
Will it be possible to build Boost 1.68.0 on Windows with Clang/LLVM?
Thx....John Cary
Yes please - doesn't work for me at present - doesn't make any .a library files. Works for me using Codeblocks on Windows to generate the library *.a files (apart from a detail in system that I have just asked about "Clang 600 and BOOST_SYSTEM_CONSTEXPR causes error_code.hpp compile failure." http://boost.2283326.n4.nabble.com/Clang-600-and-BOOST-SYSTEM-CONSTEXPR-caus... Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 6 July 2018 at 17:00, Paul A. Bristow via Boost-users < boost-users@lists.boost.org> wrote:
Yes please - doesn't work for me at present - doesn't make any .a library files.
Works for me using Codeblocks on Windows to generate the library *.a files
You write firstly "it works" and the next sentence "it doesn't work", if you expect someone to help you, you'd have to clarify. If "it works" in CB, surely you must be able to write a batch (or bash) file that does what CB does. Where does CodeBlocks (last time I looked it was an IDE) come into the picture? Surely you're using b2/bjam. There's also this article https://blogs.msdn.microsoft.com/vcblog/2017/07/19/using-mingw-and-cygwin-wi... : tl;dr VS works fine with MinGW (just do like I show you). degski --- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 7 July 2018 at 07:18, degski
There's also this article https://blogs.msdn.microsoft.com/vcblog/2017/07/19/using-mingw-and-cygwin-wi... : tl;dr VS works fine with MinGW (just do like I show you).
Or use VS Code, there you can (and have to) customize right about anything. Rong Lu has given a talk about this at CppCon17 https://www.youtube.com/watch?v=rFdJ68WbkdQ. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 6 July 2018 at 17:00, Paul A. Bristow via Boost-users < boost-users@lists.boost.org> wrote: There is also a VS plugin (by Hans Wennborg, he has written to me off list) on the way to improve Clang/VS integration. He will be going through the app-store publishing process, it seems that might take some time, and then it's good to. degski PS: apologies (too all) for the separate emails. -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 6 July 2018 at 16:32, JR Cary via Boost-users < boost-users@lists.boost.org> wrote:
Will it be possible to build Boost 1.68.0 on Windows with Clang/LLVM?
clang-cl or some mingw version of clang? degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
clang-cl On 7/6/18 9:10 AM, degski via Boost-users wrote:
On 6 July 2018 at 16:32, JR Cary via Boost-users
mailto:boost-users@lists.boost.org> wrote: Will it be possible to build Boost 1.68.0 on Windows with Clang/LLVM?
clang-cl or some mingw version of clang?
degski -- /*"If something cannot go on forever, it will stop" - Herbert Stein*/
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On 7 July 2018 at 05:36, JR Cary via Boost-users < boost-users@lists.boost.org> wrote:
clang-cl
Somewhere between 1.66 and 1.67, I've built (most) of Boost successfully, regex failed, but John fixed that almost immediately. As you see, it's quite dated (you have to update the version numbers everywhere, to make them correspond to you're setup), as I never bothered with 1.67. But as I also use Clang/LLVM, I'd like to build a thin-lto instrumented Boost for use with Clang/LLVM, so a.s.a. 1.68 comes out I'll give it a go. I used this project-config.jam file: ----------------------------------- import option ; using clang : 6.0 : "C:/Program Files/LLVM/bin/clang++.exe" : <compileflags>-fmsc-version=1911 <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe" <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe" <rc>"C:/Program Files (x86)/Windows Kits/10/bin/10.0.16299.0/x64/rc.exe" <linkflags>-fuse-ld=lld <linkflags>-flto=thin <cxxflags>-Wno-gnu-string-literal-operator-template <cxxflags>-Xclang <cxxflags>-flto-visibility-public-std <cxxflags>-fno-ms-compatibility <cxxflags>-fno-delayed-template-parsing <cxxflags>-Wno-dynamic-exception-spec # TODO: file bug to MS <cxxflags>-Wno-c++11-narrowing # TODO: wut <cxxflags>-D_WINSOCK_DEPRECATED_NO_WARNINGS # TODO: wut <cxxflags>-std=c++17 <cxxflags>-Wunused-command-line-argument <cxxflags>-DBOOST_USE_WINDOWS_H <cxxflags>-DBOOST_NO_ANSI_APIS <cxxflags>-DBOOST_USE_WINAPI_VERSION=0x1000 <cxxflags>-DBOOST_USE_WINDOWS_H=1 <cxxflags>-D_WIN32_WINNT=0x1000 <cxxflags>-D_MT <cxxflags>-D_WIN32 <cxxflags>-D_WIN64 <cxxflags>-DNOMINMAX <cxxflags>-DWIN32_LEAN_AND_MEAN <cxxflags>-D_HAS_AUTO_PTR_ETC=1 <cxxflags>-D_ITERATOR_DEBUG_LEVEL=0 <cxxflags>-D_CRT_DECLARE_NONSTDC_NAMES=1 # clang defines __STDC__, cl does not (see definition of _CRT_INTERNAL_NONSTDC_NAMES) # <cxxflags>-IC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/include # <linkflags>-LC:/PROGRA~2/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/1411~1.255/atlmfc/lib/x64 ; option.set keep-going : false ; -------------------------------------------- For the rest it's just the normal process, like with VC. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of JR Cary via Boost-users
Sent: 07 July 2018 03:37
To: degski via Boost-users
Cc: JR Cary
Subject: Re: [Boost-users] Boost 1.68.0, clang, windows
clang-cl
On 7/6/18 9:10 AM, degski via Boost-users wrote:
On 6 July 2018 at 16:32, JR Cary via Boost-users
On 7 July 2018 at 12:11, Paul A. Bristow via Boost-users < boost-users@lists.boost.org> wrote:
I’m working with Codeblocks IDE which is mingw64 based (but clang from the official site).
I can’t build libraries with b2 that are recognised (says “wrong format”).
You'll have to "tell" b2 to use the same linker (and output format as the one you're using with CB). The compiler just builds object-files, there's nothing to "recognise", so the error must be linked to the linker. C:\Temp>lld lld is a generic driver. Invoke ld.lld (Unix), ld64.lld (macOS) or lld-link (Windows) instead. You'll probably have to start with using clang++.exe, and not clang-cl.exe (although you could try clang-cl -fuse-ld=lld -flto=thin, but I guess that will still use lld-link, which will produce the same files as link.exe (the VC-one)). You can also add the clang-cl -v (verbose) option, that might give you a better idea as to what is actually going on. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On 7 July 2018 at 13:42, degski
You'll have to "tell" b2 to use the same linker (and output format as the one you're using with CB). The compiler just builds object-files, there's nothing to "recognise", so the error must be linked to the linker.
If you start with the project jam file I posted above, you'll have to add some linker specific options, I'm just guessing, but I guess there's also <linker>, and you should probably add something there (the linker you want to use), and then <linkflags> seems like a likely candidate as well, so you can totally customize what b2 will do for you. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*
On Fri, Jul 6, 2018 at 6:28 AM, Tom Kent
On Thu, Jul 5, 2018 at 9:55 PM, Marshall Clow via Boost < boost@lists.boost.org> wrote:
The release candidates for the first 1.68.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.68.0.beta.1.rc1/source/
[ snipped ]
- It looks like boost/version.hpp hasn't been updated for 1.68. It still has two instances of "67" in it, which seem to be cause the auto-linking features for visual studio to look for *-1_67.lib files, while the ones generated are *-1_68.lib. This is present in all four archive formats. Showstopper.
I agree - that's worth rolling an RC2 for. It was changed in develop, but not merged to master. - Tests for Windows/Visual Studio builds failed for msvc-10.0 in program
options:
I've pinged Vladmir about the program_options problem. -- Marshall
On Fri, Jul 6, 2018 at 10:37 AM, Marshall Clow via Boost-users
On Fri, Jul 6, 2018 at 6:28 AM, Tom Kent
wrote: On Thu, Jul 5, 2018 at 9:55 PM, Marshall Clow via Boost
wrote: The release candidates for the first 1.68.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.68.0.beta.1.rc1/source/
[ snipped ]
- It looks like boost/version.hpp hasn't been updated for 1.68. It still has two instances of "67" in it, which seem to be cause the auto-linking features for visual studio to look for *-1_67.lib files, while the ones generated are *-1_68.lib. This is present in all four archive formats. Showstopper.
I agree - that's worth rolling an RC2 for.
"Worth rolling"? That's a fairly weak observation, isn't it? The brutal fact is, show stopper is a show stopper.
It was changed in develop, but not merged to master.
- Tests for Windows/Visual Studio builds failed for msvc-10.0 in program options:
I've pinged Vladmir about the program_options problem.
-- Marshall
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (6)
-
degski
-
JR Cary
-
Marshall Clow
-
Michael Powell
-
Paul A. Bristow
-
Tom Kent