Boost 1.63.0 Release Candidate 1

The release candidates for the 1.63.0 release are now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The SHA256 checksums are as follows: 010699561c6011e6d97dc453d55bc5e54cdc192622434eff7b8ac559efac846c boost_1_63_0_rc1.7z d8ebf8d90b2f823f04119445ac339d704395d655907333ec0fab863040119d24 boost_1_63_0_rc1.tar.bz2 dabe29b8a60369ae7c15c20681a32717f3c37d97e5dc6d39c5b2fd0494b8e995 boost_1_63_0_rc1.tar.gz 1683942022fd63c205c48fb2155af6094c67ef67aa13ffb3e1db78fecf817efe boost_1_63_0_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 release managers

On Sat, Dec 10, 2016 at 11:50 AM, Marshall Clow
I have built the RC using clang (both Apple's release clang, and a fairly recent built from source version) on Mac OS X 10.11 using libc++ and C++03/11/14 and 1z. $ clang --version Apple LLVM version 8.0.0 (clang-800.0.42.1) $ totclang --version clang version 4.0.0 (trunk 289079) At all language variants, with Apple's clang, Boost.Context fails to build: It also fails to build with ToT clang at all language variants. libs/context/src/asm/make_x86_64_sysv_macho_gas.S:70:5: error: unknown use
Also, with ToT clang and C++1z, three additional failures occur: pad[cacheline_length];
field 'pad' is not used [-Wunused-private-field]
char
pad[cacheline_length];
'pad_' is not used [-Wunused-private-field]
char
pad_[cacheline_length];
/Sources/LLVM/llvm/projects/libcxx -O3 -O3 -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_DISABLE_ASSERTS -DBOOST_FIBERS_SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/fiber/build/clang-darwin-tot1z/release/link-static/threading-multi/context.o" "libs/fiber/src/context.cpp"
...failed clang-darwin.compile.c++
bin.v2/libs/fiber/build/clang-darwin-tot1z/release/link-static/threading-multi/context.o...
======
clang-darwin.compile.c++
bin.v2/libs/test/build/clang-darwin-tot1z/release/link-static/threading-multi/compiler_log_formatter.o
> 1 error generated.
>
> "/Sources/LLVM/bin/bin/clang++" -x c++ -Wno-c99-extensions
-Wno-variadic-macros -std=c++1z -stdlib=libc++ -I
/Sources/LLVM/llvm/projects/libcxx -O3 -O3 -Wno-inline -Wall -pedantic
-DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1
-DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1
-DBOOST_TIMER_STATIC_LINK=1 -DNDEBUG -I"." -c -o
"bin.v2/libs/test/build/clang-darwin-tot1z/release/link-static/threading-multi/compiler_log_formatter.o"
"libs/test/src/compiler_log_formatter.cpp"
>
> ...failed clang-darwin.compile.c++
bin.v2/libs/test/build/clang-darwin-tot1z/release/link-static/threading-multi/compiler_log_formatter.o...
>
> ======
>
> clang-darwin.compile.c++
bin.v2/libs/program_options/build/clang-darwin-tot1z/release/threading-multi/variables_map.o
> libs/program_options/src/variables_map.cpp:71:83: error: incompatible
operand types ('const basic_string<...>' and 'basic_string<...>')
> string original_token =
options.options[i].original_tokens.size() ?
>
^
> 1 error generated.
>
> "/Sources/LLVM/bin/bin/clang++" -x c++ -std=c++1z -stdlib=libc++ -I
/Sources/LLVM/llvm/projects/libcxx -O3 -O3 -Wno-inline -Wall
-DBOOST_ALL_NO_LIB=1 -DBOOST_PROGRAM_OPTIONS_DYN_LINK=1 -DNDEBUG -I"." -c
-o
"bin.v2/libs/program_options/build/clang-darwin-tot1z/release/threading-multi/variables_map.o"
"libs/program_options/src/variables_map.cpp"
>
> ...failed clang-darwin.compile.c++
bin.v2/libs/program_options/build/clang-darwin-tot1z/release/threading-multi/variables_map.o...
>
> ======
-- Marshall

On 10 December 2016 at 19:50, Marshall Clow
The release candidates for the 1.63.0 release are now available at:
Documentation: http://beta.boost.org/doc/libs/1_63_0/ Release notes: http://beta.boost.org/users/history/in_progress.html Sorry that those links are on the beta site, I'm making some changes to how the release process is handled, and it isn't quite ready yet.

On 12/11/16 08:50, Daniel James wrote:
Boost.Log docs are unreachable from that page: http://beta.boost.org/doc/libs/boost_1_63_0/libs/log/

On 11 December 2016 at 08:34, Andrey Semashev
Sorry, that's an unrelated bug in some code in development on the beta site, which I guess is why I normally don't post links to there. The live site doesn't have that issue. I've made the documentation available there: http://www.boost.org/doc/libs/1_63_0/

On Sat, Dec 10, 2016 at 8:50 PM, Marshall Clow
VS 2017 RC still fails.. C:\VC\boost>b2 C:/VC/boost/tools/build/src/tools\msvc.jam:834: in generate-setup-cmd *** argument error * rule maybe-rewrite-setup ( toolset : setup-script : setup-options : version : rewrite-setup ? ) * called with: ( msvc : : : default : ) * missing argument setup-script C:/VC/boost/tools/build/src/tools\msvc.jam:746:see definition of rule 'maybe-rewrite-setup' being called C:/VC/boost/tools/build/src/tools\msvc.jam:1076: in configure-really C:/VC/boost/tools/build/src/tools\msvc.jam:201: in configure C:/VC/boost/tools/build/src/tools\msvc.jam:153: in msvc.init C:/VC/boost/tools/build/src/build\toolset.jam:43: in toolset.using C:/VC/boost/tools/build/src/build\project.jam:1052: in using project-config.jam:3: in modules.load C:/VC/boost/tools/build/src\build-system.jam:249: in load-config C:/VC/boost/tools/build/src\build-system.jam:412: in load-configuration-files C:/VC/boost/tools/build/src\build-system.jam:524: in load C:\VC\boost\tools\build\src/kernel\modules.jam:295: in import C:\VC\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\VC\boost\boost-build.jam:17: in module scope -- Olaf

On Sat, Dec 10, 2016 at 1:50 PM, Marshall Clow
Windows builds look good. 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 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 Compile means that the b2 command completed without errors Install means that the installers for the respective version were generated 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 output is at: https://gist.github.com/teeks99/ccf20ea258050354d883b1acd93f16fc Tom

On 10 December 2016 at 19:50, Marshall Clow
The algorithm documentation is in the wrong place. It looks like it was accidentally moved into the combined documentation in the changes to automate documentation building.

pull request https://github.com/boostorg/config/pull/106 has to be merged first - than I can merge bugfixes to master

* Marshall Clow wrote:
The release candidates for the 1.63.0 release are now available at:
One thing I mentioned [1] about 1.62 and several older versions, a few days ago, is also present in this RC: In the "toolset=msvc-14.0 link=shared runtime-link=shared" build, several static libraries are built for no discernible reason. As far as I can tell by watching file system operations (using Sysinternals procmon), these libraries are not accessed again after creation. There is nothing documented about this behavior, and I suspect a bug in the build process. The unexpected files are: libboost_chrono-vc140-mt-1_63.lib libboost_system-vc140-mt-1_63.lib libboost_timer-vc140-mt-1_63.lib libboost_unit_test_framework-vc140-mt-1_63.lib These two are probably expected, because there are no DLLs built for them at all: libboost_test_exec_monitor-vc140-mt-1_63.lib libboost_exception-vc140-mt-1_63.lib Sorry for harping on this, but I still don't understand what's happening here, and would really like to. [1] http://lists.boost.org/boost-users/2016/12/86959.php -- Christian

On 12/12/16 23:12, Christian Ullrich wrote:
The same happens on Linux with gcc as well. I think there's a dependency on the static build of Boost.Test somewhere and Boost.Timer, Boost.Chrono and Boost.System are built as its dependencies. I couldn't find what library is causing the dependency on Boost.Test though. Boost.Exception only builds as a static library, as does libboost_test_exec_monitor.

* Andrey Semashev wrote:
On 12/12/16 23:12, Christian Ullrich wrote:
I just built each library separately, and the results are enlightening. Based on the list of libraries that b2 prints the building/not building status for, these are all results that are different from what I expected to get: - coroutine2: No statics, DLL for context, no output for coroutine2 - metaparse: Statics for chrono, system, timer, unit_test_framework, no output for metaparse - test: Statics and DLLs for chrono, system, test_exec_monitor, timer, DLLs for prg_exec_monitor, unit_test_framework, no output explicitly named "test" I did not attempt python, and had no build activity for mpi and graph_parallel, which is clearly due to missing external dependencies. However, I found the culprit, and it looks like I've been chasing wild geese all the time. test has a dependency on timer, which pulls in chrono and system. Building --without-test gives, at last, the expected result. Anyway, libs/metaparse/build/Jamfile.v2 looks like it may not be meant to be used when building all libraries, and I think there is something wrong with coroutine2 also; its config.hpp and Jamfile.v2 do not seem quite clear on whether it is "coroutine" or "coroutine2" or "couroutines2". But I'm just guessing here. -- Christian

please add two patches in order to fix two bugs: e71b38c1d2cc8ab6d896eeeff012ba9a934e583b bb8b7f5dbf0015232e08906378c49d0af57eb6e1 (boost.context, branch master)

please add commit fffb7e7f320162775382d73ea0ac5434d7d55f0e (boost.fiber) to boost-1.63.0 - the patches fixes the mingw issue

As I mentioned to Marshall, the results here: http://www.boost.org/development/tests/develop/developer/config.html are horribly outdated - are they actually being run and updated? John.

On Tue, Dec 20, 2016 at 10:52 AM, Edward Diener
I was not aware of the stalled results.. Investigating now. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 12/20/16 22:40, Belcourt, Kenneth wrote:
The latest results from Sandia that I can see are from 12th. The report info[1] also says it was run last time on 12th. [1]: http://www.boost.org/development/tests/develop/developer/index.html

On Tue, Dec 20, 2016 at 2:36 PM, Andrey Semashev
The report generation issue is now addressed. The results are current and show tests from today. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
participants (12)
-
Andrey Semashev
-
Belcourt, Kenneth
-
Christian Ullrich
-
Daniel James
-
Edward Diener
-
John Maddock
-
Marshall Clow
-
Olaf van der Spek
-
Oliver Kowalke
-
Rene Rivera
-
Stefan Seefeld
-
Tom Kent