[1.51.0] Beta 1 release candidates available
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/ 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. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z Thanks, --The release managers
On Wed, Aug 1, 2012 at 4:40 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z
on Ubuntu 12.04 32-bit ./bootstrap.sh && ./b2 (from the .tar.bz2) works ok with gcc 4.6.3. and ./bootstrap.sh --with-toolset=clang && ./b2 (from the .tar.bz2) works ok with clang 3.0 Best, Matus
On 1.8.2012 5:40, Marshall Clow wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
Hello, at least MSVC (could be others, too, this is a compiler specific jam-file issue) fails to fully compile Boost.Context if there's any user specified preprocessor define passed to B2 that has characters that command prompt may interpter as control characters, e.g. ``define=BOOST_USER_CONFIG="<SuperiorConfig>"'' that is. The problem lies in how tools\build\v2\tools\msvc.jam handles .ASM (and .RC files, too, not that Boost yet uses any during the build) files: line 314: actions compile.asm { $(.ASM) -c -Zp4 -Cp -Cx -D$(DEFINES) $(ASMFLAGS) $(USER_ASMFLAGS) -Fo "$(<:W)" "$(>:W)" } As command line is not passed thru a .RSP file (just a normal text file where the rest of the command line arguments are read) unlike compile.asm's (and .rc's) counterparts do, characters such as "<" and ">" affect the control flow, which in this case is not what user wants (at least not what *I* want :D). So, as a fix I propose that either do a full .RSP treatment or simply enclose defines inside a double quotes ("-D$(DEFINES)"); That should fix it. (Not sure if $(INCLUDES) should be passed to $(.ASM), in this particular example it's the not the root cause anyway [<SuperiorConfig> not being found due to missing include path] as no .ASM file currently actually includes any [external] file.) -- Pekka
(cc'ing boost-build) On 8/1/2012 5:18 AM, Pekka Seppänen wrote:
On 1.8.2012 5:40, Marshall Clow wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
Hello,
at least MSVC (could be others, too, this is a compiler specific jam-file issue) fails to fully compile Boost.Context if there's any user specified preprocessor define passed to B2 that has characters that command prompt may interpter as control characters, e.g. ``define=BOOST_USER_CONFIG="<SuperiorConfig>"'' that is.
The problem lies in how tools\build\v2\tools\msvc.jam handles .ASM (and .RC files, too, not that Boost yet uses any during the build) files:
line 314: actions compile.asm { $(.ASM) -c -Zp4 -Cp -Cx -D$(DEFINES) $(ASMFLAGS) $(USER_ASMFLAGS) -Fo "$(<:W)" "$(>:W)" }
As command line is not passed thru a .RSP file (just a normal text file where the rest of the command line arguments are read) unlike compile.asm's (and .rc's) counterparts do, characters such as "<" and ">" affect the control flow, which in this case is not what user wants (at least not what *I* want :D).
So, as a fix I propose that either do a full .RSP treatment or simply enclose defines inside a double quotes ("-D$(DEFINES)"); That should fix it.
(Not sure if $(INCLUDES) should be passed to $(.ASM), in this particular example it's the not the root cause anyway [<SuperiorConfig> not being found due to missing include path] as no .ASM file currently actually includes any [external] file.)
Thanks for the report Pekka. This doesn't seem like something that should hold up the beta, but hopefully someone can fix it for release. -- Eric Niebler BoostPro Computing http://www.boostpro.com
tar xjf ~/boost_1_51_0_beta1_rc1.tar.bz2 tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-t: Operation not permitted tar: Exiting with failure status due to previous errors
On 8/1/2012 6:40 AM, Neal Becker wrote:
tar xjf ~/boost_1_51_0_beta1_rc1.tar.bz2 tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-t: Operation not permitted tar: Exiting with failure status due to previous errors
Neal, I'm unable to reproduce this error on my Linux VM (Ubuntu latest). What platform are you on? Dumb question: are you sure you're doing it in a directory you have write access to? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Aug 1, 2012, at 7:42 AM, Eric Niebler <eric@boostpro.com> wrote:
On 8/1/2012 6:40 AM, Neal Becker wrote:
tar xjf ~/boost_1_51_0_beta1_rc1.tar.bz2 tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-t: Operation not permitted tar: Exiting with failure status due to previous errors
Neal, I'm unable to reproduce this error on my Linux VM (Ubuntu latest). What platform are you on? Dumb question: are you sure you're doing it in a directory you have write access to?
Neal has pointed to to me (off list) that some of the directories in the tar ball have 0700 perms, while others have 0755 (which is, of course, what we want). I'm looking into it. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Tue, Jul 31, 2012 at 07:40:35PM -0700, Marshall Clow wrote:
The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z
Many thanks for the distinctly named filenames. -- Lars Viklund | zao@acc.umu.se
On Tue, Jul 31, 2012 at 10:40 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
The build of these distribution files marks a nice step forward for release management: The files are being built with a new script written by Marshall in python. That allows building release filess on any modern operating system. The old scripts were Windows specific, and Beman was the only release manager who knew how to run them Marshall built the files for this release, and he and Beman will alternate building releases so that both stay familiar with the process. This will eliminate a dependency on any one person. Thanks to Marshall for taking this on! --Beman
On Tue, Jul 31, 2012 at 10:40 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z
Thanks,
--The release managers
Could we change the directory that is packed into the zipped archive to be the same as the archive name? For example, if we have boost_1_51_0_beta1_rc1.tar.gz the directory name should be boost_1_51_0_beta1_rc1 not simply boost_1_51_0_beta1. The only reason I ask is because my build script expects it...if there's good reasons for making rc's have a different archive name I'm open to it. Tom Kent
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Aug 1, 2012 at 8:37 PM, Tom Kent <lists@teeks99.com> wrote:
On Tue, Jul 31, 2012 at 10:40 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z
Thanks,
--The release managers
Could we change the directory that is packed into the zipped archive to be the same as the archive name? For example, if we have boost_1_51_0_beta1_rc1.tar.gz the directory name should be boost_1_51_0_beta1_rc1 not simply boost_1_51_0_beta1.
The only reason I ask is because my build script expects it...if there's good reasons for making rc's have a different archive name I'm open to it.
Tom Kent
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
My mistake. This was only a problem with the _rc2 files, the _rc1 files are actually how I asked for them. Is this a bug in the build for _rc2? Tom
On Aug 1, 2012, at 5:47 PM, Tom Kent <lists@teeks99.com> wrote:
On Wed, Aug 1, 2012 at 8:37 PM, Tom Kent <lists@teeks99.com> wrote:
On Tue, Jul 31, 2012 at 10:40 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z
Thanks,
--The release managers
Could we change the directory that is packed into the zipped archive to be the same as the archive name? For example, if we have boost_1_51_0_beta1_rc1.tar.gz the directory name should be boost_1_51_0_beta1_rc1 not simply boost_1_51_0_beta1.
The only reason I ask is because my build script expects it...if there's good reasons for making rc's have a different archive name I'm open to it.
Tom Kent
My mistake. This was only a problem with the _rc2 files, the _rc1 files are actually how I asked for them. Is this a bug in the build for _rc2?
This was a bug fix for rc2. The idea is that when we declare beta1, we just rename the last "release candidate", instead of regenerating the archives. That way we know that nothing has changed between _rcN and final. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Wed, Aug 01, 2012 at 08:37:20PM -0400, Tom Kent wrote:
Could we change the directory that is packed into the zipped archive to be the same as the archive name? For example, if we have boost_1_51_0_beta1_rc1.tar.gz the directory name should be boost_1_51_0_beta1_rc1 not simply boost_1_51_0_beta1.
The only reason I ask is because my build script expects it...if there's good reasons for making rc's have a different archive name I'm open to it.
Ooh, the folders inside are explicitly named? That's nice. I asked explictly for the explicit naming of archives during the last beta cycle. It's _very_ frustrating having to verify every single boost_1_50_0 tarball you encounter until the end of time, just because you might at some point in time have grabbed a RC. I would very much like it if the unpacked directory was marked or labelled somehow, either by name or by additional content, the more the merrier. It really sucks running into content you cannot tell if it's the real deal or a prerelease with lots of amusing bugs and quirks. -- Lars Viklund | zao@acc.umu.se
Hi.
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
boost_1_51_0_beta1_rc1.7z builds correctly on Windows 7/x64 with msvc-9.0 using both the trunk Boost Build and the one included in the distribution. Command-line: bjam.exe stage --stagedir=xxx --without-mpi --build-type=complete Hope this helps. Best regards, Jurko Gospodnetić P.S. Uff, seems I took too long with this and RC2 is already out... off to test that as well... :-)
Le 01/08/12 04:40, Marshall Clow a écrit :
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
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.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z
Hi, could I merge the fix for ticket https://svn.boost.org/trac/boost/ticket/6174 after regression test cycle? Best, Vicente svn diff future.hpp ../../libs/thread/test/test_6174.cpp Index: future.hpp =================================================================== --- future.hpp (revision 79979) +++ future.hpp (working copy) @@ -484,7 +484,7 @@ void mark_finished_with_result(rvalue_source_type result_) { boost::lock_guard<boost::mutex> lock(mutex); - mark_finished_with_result_internal(result_); + mark_finished_with_result_internal(static_cast<rvalue_source_type>(result_)); } move_dest_type get() Index: ../../libs/thread/test/test_6174.cpp =================================================================== --- ../../libs/thread/test/test_6174.cpp (revision 79973) +++ ../../libs/thread/test/test_6174.cpp (working copy) @@ -1,5 +1,10 @@ +// Copyright (C) 2010 Vicente Botet +// +// Distributed under the Boost Software License, Version 1.0. (See accompanying +// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) + #include <boost/thread.hpp> #include <boost/config.hpp> @@ -16,13 +21,21 @@ public: MovableButNonCopyable() {}; MovableButNonCopyable(MovableButNonCopyable&&) {}; - MovableButNonCopyable& operator=(MovableButNonCopyable&&) { + MovableButNonCopyable& operator=(MovableButNonCopyable&&) + { return *this; }; }; + +MovableButNonCopyable construct() +{ + return MovableButNonCopyable(); +} + int main() { - boost::packaged_task<MovableButNonCopyable>(MovableButNonCopyable()); + boost::packaged_task<MovableButNonCopyable> pt(construct); + pt(); return 0; } #else frlann0l016992:thread viboes$ svn ci future.hpp ../../libs/thread/test/test_6174.cpp -m "Thread: refix 6174" Sending boost/thread/future.hpp Sending libs/thread/test/test_6174.cpp Transmitting file data .. Committed revision 79980.
On 8/12/2012 9:44 AM, Vicente J. Botet Escriba wrote:
Hi,
could I merge the fix for ticket https://svn.boost.org/trac/boost/ticket/6174 after regression test cycle?
Best, Vicente
After the tests cycle, yes. You have until Thursday, when we start building the RC. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (10)
-
Beman Dawes -
Eric Niebler -
Jurko Gospodnetić -
Lars Viklund -
Marshall Clow -
Matus Chochlik -
Neal Becker -
Pekka Seppänen -
Tom Kent -
Vicente J. Botet Escriba