On Sat, Mar 19, 2016 at 1:58 PM, Marshall Clow wrote:

On Sat, Mar 19, 2016 at 12:38 PM, Vladimir Prus wrote:

...

Release candidates for 1.61.0 beta 1 are now available:

http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z

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.

Packaging: The .gz file expanded to "boost_master_3a94cde635254f92fa87e0e11ef52d08684b8225", instead of "boost_1_61_0_b1"

I successfully built the libraries with Apple's clang compiler. "Apple LLVM version 7.0.2 (clang-700.1.81)" with C++03, C++11, C++14, and c++1z

I was not successful building the libraries with clang ToT. Boost.Python, in particular, had compile errors. I don't know if this is a problem in Boost.Python, or in libc++. (probably libc++)

Definitely a libc++ problem. -- Marshall

On Sat, Mar 19, 2016 at 4:02 PM, Marcel Raad wrote:

Vladimir Prus-4 wrote

...

Release candidates for 1.61.0 beta 1 are now available:

http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z

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.

These packages were generated by the CI system that Rene has put together, and one user-visible change is that the directory inside archive is named after git commit hash. This will be changed for the final release. Otherwise, these were smoke-tested on Windows and Linux, and should be functionally identical to usual packages.

The 7zip archive now has Unix line endings instead of Windows line endings.

Hmm.. I'll check that later today.. But in case you can answer faster than I can check.. Are the EOLs also incorrect for the ZIP archive? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Hi, With Visual Studio 2015 update 1 on Windows 7, I get the following Boost.Python build error (I do not have Python installed on this particular machine) compile-c-c++ bin.v2\libs\python\build\msvc-14.0\release\address-model-64\link-static\threading-mult i\list.obj list.cpp .\boost/python/detail/wrap_python.hpp(50): fatal error C1083: Cannot open include file: 'pyconfig.h' : No such file or directory Building again with "--without-python" fixes it but I've not had to do that before. The rest of Boost built fine. Cheers Mark. -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-61-0-Beta-1-Release-Candidate-1-t... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Sun, Mar 20, 2016 at 7:35 AM, Tom Kent wrote:

On Sat, Mar 19, 2016 at 2:38 PM, Vladimir Prus wrote:

...

Release candidates for 1.61.0 beta 1 are now available:

http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z

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.

These packages were generated by the CI system that Rene has put together, and one user-visible change is that the directory inside archive is named after git commit hash. This will be changed for the final release. Otherwise, these were smoke-tested on Windows and Linux, and should be functionally identical to usual packages.

I'd like to request that we roll a 1_61_0_b2 without this change. The directory structure is a big part of what we need to verify and this throws off the build system that I've had running.

I meant "rc2" not "b2".

Other than that, everything seems to work correctly:

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.

Tom

On Sun, Mar 20, 2016 at 9:07 AM, Rene Rivera wrote:

On Sun, Mar 20, 2016 at 5:35 AM, Tom Kent wrote:

...

On Sat, Mar 19, 2016 at 2:38 PM, Vladimir Prus wrote:

...

Release candidates for 1.61.0 beta 1 are now available:

http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z

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.

These packages were generated by the CI system that Rene has put

together,

...

and one user-visible change is that the directory inside archive is named after git commit hash. This will be changed for the final release. Otherwise, these were smoke-tested on Windows and Linux, and should be functionally identical to usual packages.

I'd like to request that we roll a 1_61_0_b2 without this change. The directory structure is a big part of what we need to verify and this throws off the build system that I've had running.

Ah.. The directory structure is the same. Only the top level dir is different. Could you be specific as to how it throws off your build?

My build script looks for a directory in the pattern of the build version. It isn't the end of the world, and I could write a work-around, but I think it would be better to have the version in the directory name that it extracts to. It might be good, however, to include the commit id in a text file within the build though. Tom

Louis Dionne wrote

[...]

I just realized that I forgot to bump the version macros in Hana. Basically, I planned to move Hana into version 1.0.0 for its first release in Boost, but I left it at 0.8.0. How can I fix this situation? Would pushing the new changes to 'master' fix things?

I apologize for any trouble that could cause to the release process.

Louis

For some reason, I did not see other people's messages on this thread (the GMane interface seems to leave out a lot of messages), but that would have addressed my question. I assume I must simply wait for master to reopen for bugfixes? Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-61-0-Beta-1-Release-Candidate-1-t... Sent from the Boost - Dev mailing list archive at Nabble.com.

2016-03-21 13:50 GMT+01:00 Damian Vicino :

...

Release candidates for 1.61.0 beta 1 are now available:

http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z

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 tested default build in “15.3.0 Darwin Kernel Version"

And got this results: … clang-darwin.link.dll bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/libboost_context.dylib Undefined symbols for architecture x86_64: "boost::thread_detail::enter_once_region(boost::once_flag&)", referenced from: boost::context::stack_traits::is_unbounded() in stack_traits.o boost::context::stack_traits::page_size() in stack_traits.o boost::context::stack_traits::default_size() in stack_traits.o boost::context::stack_traits::maximum_size() in stack_traits.o "boost::thread_detail::commit_once_region(boost::once_flag&)", referenced from: boost::context::stack_traits::is_unbounded() in stack_traits.o boost::context::stack_traits::page_size() in stack_traits.o boost::context::stack_traits::default_size() in stack_traits.o boost::context::stack_traits::maximum_size() in stack_traits.o "boost::system::system_category()", referenced from: __GLOBAL__sub_I_stack_traits.cpp in stack_traits.o "boost::system::generic_category()", referenced from: __GLOBAL__sub_I_stack_traits.cpp in stack_traits.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

"clang++" -o "bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/libboost_context.dylib" -single_module -dynamiclib -install_name "@rpath/libboost_context.dylib" "bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/asm/make_x86_64_sysv_macho_gas.o" "bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/asm/jump_x86_64_sysv_macho_gas.o" "bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/asm/ontop_x86_64_sysv_macho_gas.o" "bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/posix/stack_traits.o" "bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/execution_context.o"

...failed clang-darwin.link.dll bin.v2/libs/context/build/clang-darwin-4.2.1/release/threading-multi/libboost_context.dylib... ...skipped libboost_context.dylib for lack of libboost_context.dylib... ...skipped libboost_coroutine.dylib for lack of libboost_context.dylib... ...skipped libboost_coroutine.dylib for lack of libboost_coroutine.dylib... ...failed updating 1 target... ...skipped 3 targets...

maybe 'b2 --reconfigure toolset ....' does solve the issue