[1.47.0] Beta 1 Release candidate files available
Release candidate files for 1.47.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. Thanks, --The release managers PS: I've downloaded and built the Windows 7z file. No problems.
On Mon, Jun 20, 2011 at 3:19 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.47.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.
The .tar.bz2 bootstraps and builds without errors - on Debian-64bit with gcc 4.6.0 - on Ubuntu-32bit with gcc 4.5.1 The .zip bootstraps and builds without errors (with some warnings) - on Vista-32bit with msvc-9.0 full output of ./bjam can be found here: http://kifri.fri.uniza.sk/~chochlik/boost_1_47_0_beta1_build/ Best, Matus
On 20 June 2011 16:10, Matus Chochlik <chochlik@gmail.com> wrote:
On Mon, Jun 20, 2011 at 3:19 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.47.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.
The .tar.bz2 bootstraps and builds without errors - on Debian-64bit with gcc 4.6.0 - on Ubuntu-32bit with gcc 4.5.1
The .zip bootstraps and builds without errors (with some warnings) - on Vista-32bit with msvc-9.0
full output of ./bjam can be found here:
http://kifri.fri.uniza.sk/~chochlik/boost_1_47_0_beta1_build/
Best,
Matus _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The .tar.bz2 builds without errors on OS X 10.6.7 with both gcc 4.2.1 (the default shipped by Apple) and clang 2.9. The build logs can be found at: http://vexocide.org/boost/os_x_10.6.7-64_bit-gcc_4.2.1.txt and http://vexocide.org/boost/os_x_10.6.7-64_bit-clang_2.9.txt. Regards, Jeroen
build the Windows zip file and tested it on Win7 64bit. Build successfully. On Mon, Jun 20, 2011 at 4:19 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.47.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.
Thanks,
--The release managers
PS: I've downloaded and built the Windows 7z file. No problems. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Build successfully with MSVC 2010 SP1. However, there are some warnings. Log file attached. Best, Lior Kogan On Mon, Jun 20, 2011 at 4:19 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.47.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.
Thanks,
--The release managers
PS: I've downloaded and built the Windows 7z file. No problems. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Jun 20, 2011 at 09:19:00AM -0400, Beman Dawes wrote:
Release candidate files for 1.47.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.
Would it be possible to coax your tar implementation to author files with less extreme GIDs. The current ones (4294967295) lead to massive amounts of console spam on operating systems where IDs are uint16_t (mingw) or int32_t (assorted BSD). On mingw - tar: Archive value 4294967295 is out of gid_t range 0..65535 I did not try building it yet, but I felt that this is a good time to mention this niggle that has been plaguing me for many releases. -- Lars Viklund | zao@acc.umu.se
On 6/20/2011 12:23 PM, Lars Viklund wrote:
On mingw - tar: Archive value 4294967295 is out of gid_t range 0..65535
Ah.. Shouldn't you be using the zip/7z with mingw? As the EOLs will be wrong otherwise. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Successful builds of boost_1_47_0_beta1.tar.bz2 on Linux Ubuntu x86_64 using toolsets gcc-4.5, clang-2.8, intel-12.0.3 Best regards, Antony Polukhin
On Mon, Jun 20, 2011 at 1:23 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Jun 20, 2011 at 09:19:00AM -0400, Beman Dawes wrote:
Release candidate files for 1.47.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.
Would it be possible to coax your tar implementation to author files with less extreme GIDs.
The current ones (4294967295) lead to massive amounts of console spam on operating systems where IDs are uint16_t (mingw) or int32_t (assorted BSD).
The tar being used is tar (GNU tar) 1.25 Packaged by Cygwin (1.25-1) The command used is: tar cfz %1.tar.gz %1 I'm not a regular tar user, so would need advice on how to solve the problem. I don't even know what a GID is. Suggestions welcomed! --Beman
On Mon, 20 Jun 2011, Beman Dawes wrote:
On Mon, Jun 20, 2011 at 1:23 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Jun 20, 2011 at 09:19:00AM -0400, Beman Dawes wrote:
Release candidate files for 1.47.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.
Would it be possible to coax your tar implementation to author files with less extreme GIDs.
The current ones (4294967295) lead to massive amounts of console spam on operating systems where IDs are uint16_t (mingw) or int32_t (assorted BSD).
The tar being used is tar (GNU tar) 1.25 Packaged by Cygwin (1.25-1)
The command used is:
tar cfz %1.tar.gz %1
I'm not a regular tar user, so would need advice on how to solve the problem. I don't even know what a GID is.
There are --owner=n and --group=n flags to GNU tar for creating archives; the info page suggests that both are often set to 0, which should fix the problem. -- Jeremiah Willcock
On Mon, Jun 20, 2011 at 4:02 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Mon, 20 Jun 2011, Beman Dawes wrote:
... The tar being used is tar (GNU tar) 1.25 Packaged by Cygwin (1.25-1)
The command used is:
tar cfz %1.tar.gz %1
I'm not a regular tar user, so would need advice on how to solve the problem. I don't even know what a GID is.
There are --owner=n and --group=n flags to GNU tar for creating archives; the info page suggests that both are often set to 0, which should fix the problem.
The --help message says: --group=NAME force NAME as group for added files --owner=NAME force NAME as owner for added files so is --numeric-owner also required? --numeric-owner always use numbers for user/group names --Beman
On Mon, Jun 20, 2011 at 1:23 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Jun 20, 2011 at 09:19:00AM -0400, Beman Dawes wrote:
Release candidate files for 1.47.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.
Would it be possible to coax your tar implementation to author files with less extreme GIDs.
The current ones (4294967295) lead to massive amounts of console spam on operating systems where IDs are uint16_t (mingw) or int32_t (assorted BSD).
On mingw - tar: Archive value 4294967295 is out of gid_t range 0..65535
I was able to reproduce this from the mingw command prompt. A fix has been committed per the suggestion from Jeremiah Willcock, and it worked when tested locally. A off schedule daily snapshot is running now, so when it finishes in a half-hour or so you should be able to try it yourself. Please report results. Thanks for the report, and thanks to Jeremiah for his fix suggestion. --Beman
On Tue, Jun 21, 2011 at 11:36:53AM -0400, Beman Dawes wrote:
On Mon, Jun 20, 2011 at 1:23 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Jun 20, 2011 at 09:19:00AM -0400, Beman Dawes wrote:
Release candidate files for 1.47.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.
Would it be possible to coax your tar implementation to author files with less extreme GIDs.
The current ones (4294967295) lead to massive amounts of console spam on operating systems where IDs are uint16_t (mingw) or int32_t (assorted BSD).
On mingw - tar: Archive value 4294967295 is out of gid_t range 0..65535
I was able to reproduce this from the mingw command prompt.
A fix has been committed per the suggestion from Jeremiah Willcock, and it worked when tested locally. A off schedule daily snapshot is running now, so when it finishes in a half-hour or so you should be able to try it yourself. Please report results.
My mingw's tar is blissfully quiet now, excellent. I'll spin up a BSD VM to test that later, but the UID/GIDs chosen (0) should be in range on _any_ system.
Thanks for the report, and thanks to Jeremiah for his fix suggestion.
-- Lars Viklund | zao@acc.umu.se
On 20 June 2011 14:19, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.47.0 beta 1 are available at http://boost.cowic.de/rc/
I uploaded the documentation to the beta site, at: http://beta.boost.org/doc/libs/1_47_0_beta1/ Most links from the release notes should now work - unless they explicitly link to the 1_47_0.
Thanks to all those who responded so quickly. Since no serious packaging issues have come up, I planning to push the files up to sourceforge ASAP. --Beman
Hi Beman, Daniel, On 20-6-2011 21:40, Beman Dawes wrote:
Thanks to all those who responded so quickly. Since no serious packaging issues have come up, I planning to push the files up to sourceforge ASAP.
Great. I found one remarkable thing, don't know if it is a problem. The file boost-release-docs.7z contains docs for some (but not all) libraries in the html folder. There is also a libs folder containing only the docs of Boost.Geometry. What is the reason for that? Just checked the beta website mailed by Daniel, and there everything looks OK including the latest version. Regards, Barend
On 20 June 2011 20:46, Barend Gehrels <barend@xs4all.nl> wrote:
I found one remarkable thing, don't know if it is a problem. The file boost-release-docs.7z contains docs for some (but not all) libraries in the html folder. There is also a libs folder containing only the docs of Boost.Geometry. What is the reason for that?
That's the documentation that I build and upload. Beman's release scripts downloads it and adds it to the release, so that he doesn't have to build the documentation.
Hi Daniel, On 20-6-2011 21:58, Daniel James wrote:
I found one remarkable thing, don't know if it is a problem. The file boost-release-docs.7z contains docs for some (but not all) libraries in the html folder. There is also a libs folder containing only the docs of Boost.Geometry. What is the reason for that? That's the documentation that I build and upload. Beman's release
On 20 June 2011 20:46, Barend Gehrels<barend@xs4all.nl> wrote: scripts downloads it and adds it to the release, so that he doesn't have to build the documentation.
OK, perfect. Thanks, Barend
Daniel James wrote:
On 20 June 2011 20:46, Barend Gehrels <barend@xs4all.nl> wrote:
I found one remarkable thing, don't know if it is a problem. The file boost-release-docs.7z contains docs for some (but not all) libraries in the html folder. There is also a libs folder containing only the docs of Boost.Geometry. What is the reason for that?
That's the documentation that I build and upload. Beman's release scripts downloads it and adds it to the release, so that he doesn't have to build the documentation.
I think this is the source of a very annoying (for me) problem. I maintain a local copy of the boost release from SVN. This lets me test my own changes against the next release so any problem that occurs is almost for certain my own. I'm almost guarenteed that when my locao changes migrate through the trunk to the release branch there will be no problems. Also, since the release branch updates far less frequently, it's much easier for me to keep in sync. So far so good. But there is one big pain - and that's the boost documentation. It seems it's not part of the release tree but rather built separately and merged into the release. This means that I don't really have the latest documentation available as I do the code. That is, they are not in sync. I would like to be developing other projects against the "next release" but the lack of the latest documentation is unhelpful. Couldn't we do the following? Fix up the bjam scripts so that directories look like: root/libs/mylib/doc/html/... And every day do an incremental rebuild of the html directories. This shouldn't take a lot of time since release doesn't change that often and when it does, only that documentation which is changed has to be re-generated. Now I can just use my release branch mirror for development, etc - just like I owuld use for the release. I would effectively have the "point release" sitting on my desk and I could update from the release branch when it was convenient to me. The release managers's job would then be almost trivial: a) make announcements b) freeze the release branch for a week or two before release c) give wavers to those who can't make the schedule. d) tag and build the release for shipment. e) re-open the release branch for commits.
From my stand point I wouldn't have to get the latest release and rebuild it just to get updated documentation.
If everyone did it this way, the "next" release would be continuously tested in addition to the official testers. Robert Ramey
On 20 June 2011 23:12, Robert Ramey <ramey@rrsd.com> wrote:
But there is one big pain - and that's the boost documentation. It seems it's not part of the release tree but rather built separately and merged into the release. This means that I don't really have the latest documentation available as I do the code.
If you open the documentation index html files they will redirect to the last build of the trunk documentation. If you navigate from the root/libraries html file that should happen seamlessly (unless you're offline, in which case there's not much I can do). It shouldn't be that hard to write a script to download boost-release-docs.7z and extract that into a local copy.
Fix up the bjam scripts so that directories look like:
root/libs/mylib/doc/html/...
That would break a lot of documentation, and I'm not sure what it would gain.
And every day do an incremental rebuild of the html directories. This shouldn't take a lot of time since release doesn't change that often and when it does, only that documentation which is changed has to be re-generated.
That isn't possible with the current build system. We need to clear out the html files each time because it generates different file names.
The release managers's job would then be almost trivial:
AFAICT the documentation part of the release process is working well. I don't think it's the cause of any effort required during release.
Beman Dawes wrote:
Release candidate files for 1.47.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.
I've downloaded boost_1_47_0_beta1.zip file, decompressed it and run ./booststrap.sh under mingw. I've got the following errors ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c builtins.c:32:23: fatal error: sys/wait.h: No such file or directory compilation terminated. execunix.c:17:26: fatal error: sys/resource.h: No such file or directory compilation terminated. fileunix.c:98:17: fatal error: ar.h: No such file or directory compilation terminated. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/1-47-0-Beta-1-Release-candidate-files-ava... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet wrote:
Beman Dawes wrote:
Release candidate files for 1.47.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.
I've downloaded boost_1_47_0_beta1.zip file, decompressed it and run ./booststrap.sh under mingw. I've got the following errors
### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c builtins.c:32:23: fatal error: sys/wait.h: No such file or directory compilation terminated. execunix.c:17:26: fatal error: sys/resource.h: No such file or directory compilation terminated. fileunix.c:98:17: fatal error: ar.h: No such file or directory compilation terminated.
What mingw specifically? - Volodya -- Vladimir Prus CodeSourcery / Mentor Graphics +7 (812) 677-68-40
On 20/06/2011 14:19, Beman Dawes wrote:
Release candidate files for 1.47.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.
Setup: <http://www.boost.org/development/tests/release/KTC-Win7x64_VC10x64.html> Command: bjam --stagedir=x64 --build-type=complete -j2 architecture=x86 address-model=64 stage bjam --without-python --stagedir=x86 --build-type=complete -j2 stage Both result in: "...failed updating 2 targets..." See <http://pastebin.com/s7Cvw2Tm> for failure. KTC
Hi, On Tuesday, 21. June 2011 13:47:18 KTC wrote:
On 20/06/2011 14:19, Beman Dawes wrote: Setup: <http://www.boost.org/development/tests/release/KTC-Win7x64_VC10x64.html>
Command: bjam --stagedir=x64 --build-type=complete -j2 architecture=x86 address-model=64 stage bjam --without-python --stagedir=x86 --build-type=complete -j2 stage
Both result in: "...failed updating 2 targets..." See <http://pastebin.com/s7Cvw2Tm> for failure.
Boost.Exceptions is a library on Win32. It builds "libs/exception/src/clone_current_exception_msvc.cpp" which states at the top: #if defined(_MSC_VER) && defined(_M_IX86) && !defined(_M_X64) so this is for x86 only. On x64, no code gets compiled. The msvc linker then "helpfully" silently omits the creation of an empty dll and the corresponding copy step(s) fail(s). The correct fix would be to build this file only on for the <address-model>32 case but I don't know if this can be specified with the current Boost.Build. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Beman Dawes wrote:
Release candidate files for 1.47.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 Boost 1.47.0 beta 1 built fine using gcc 4.5.1. (on OpenSuSE 11.4 32 bit).
There seems to be an issue with Spirit, though. (My code did compile but failed to parse its input.) I have sent a message about to the Spirit ML. Best regards Christoph
Beman Dawes <bdawes <at> acm.org> writes:
Release candidate files for 1.47.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.
Thanks,
--The release managers
PS: I've downloaded and built the Windows 7z file. No problems.
The .7z package built without errors with MSVC 2010 SP1 for both x86 and x64, but in all cases I see the following in bjam's output:
common.copy stage\lib\boost_exception-vc100-mt-gd-1_47.lib The system cannot find the file specified.
copy /b "bin.v2\libs\exception\build\msvc-10.0\debug\address-model- 32\architecture-x86\extern-c-nothrow-on\threading-multi\boost_exception-vc100- mt-gd-1_47.lib" + this-file-does-not-exist-A698EE7806899E69 "stage\lib\boost_exception-vc100-mt-gd-1_47.lib"
...failed common.copy stage\lib\boost_exception-vc100-mt-gd-1_47.lib...
...
...failed updating 1 target...
I'm not sure if this is intentional and/or benign, but I thought it was worth mentioning. I've hosted the bjam output in case it's relevant: [1] http://dl.dropbox.com/u/10282384/x86debug.txt [2] http://dl.dropbox.com/u/10282384/x86release.txt [3] http://dl.dropbox.com/u/10282384/x64debug.txt [4] http://dl.dropbox.com/u/10282384/x64release.txt
On Wed, Jun 22, 2011 at 1:32 PM, Adam Merz <adammerz@hotmail.com> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Release candidate files for 1.47.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.
Thanks,
--The release managers
PS: I've downloaded and built the Windows 7z file. No problems.
The .7z package built without errors with MSVC 2010 SP1 for both x86 and x64, but in all cases I see the following in bjam's output:
common.copy stage\lib\boost_exception-vc100-mt-gd-1_47.lib The system cannot find the file specified.
copy /b "bin.v2\libs\exception\build\msvc-10.0\debug\address-model- 32\architecture-x86\extern-c-nothrow-on\threading-multi\boost_exception-vc100- mt-gd-1_47.lib" + this-file-does-not-exist-A698EE7806899E69 "stage\lib\boost_exception-vc100-mt-gd-1_47.lib"
...failed common.copy stage\lib\boost_exception-vc100-mt-gd-1_47.lib...
To clarify, the failure is of course for `boost_exception-vc100-mt-1_47.lib' rather than `boost_exception-vc100-mt-gd-1_47.lib' for release builds.
...
...failed updating 1 target...
I'm not sure if this is intentional and/or benign, but I thought it was worth mentioning. I've hosted the bjam output in case it's relevant:
[1] http://dl.dropbox.com/u/10282384/x86debug.txt [2] http://dl.dropbox.com/u/10282384/x86release.txt [3] http://dl.dropbox.com/u/10282384/x64debug.txt [4] http://dl.dropbox.com/u/10282384/x64release.txt
Has there been any resolution of this problem? --Beman
Beman Dawes <bdawes <at> acm.org> writes:
On Wed, Jun 22, 2011 at 1:32 PM, Adam Merz <adammerz <at> hotmail.com> wrote:
<snip> I'm not sure if this is intentional and/or benign, but I thought it was worth mentioning. I've hosted the bjam output in case it's relevant:
[1] http://dl.dropbox.com/u/10282384/x86debug.txt [2] http://dl.dropbox.com/u/10282384/x86release.txt [3] http://dl.dropbox.com/u/10282384/x64debug.txt [4] http://dl.dropbox.com/u/10282384/x64release.txt
Has there been any resolution of this problem?
--Beman
Is this question directed at myself or Emil (or someone else)? If myself, then has the 1.47 beta been repackaged since it was initially made available? I only have the .7z package from boost.cowic.de that I downloaded on the 21st.
On Tue, Jun 28, 2011 at 2:27 PM, Adam Merz <adammerz@hotmail.com> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
On Wed, Jun 22, 2011 at 1:32 PM, Adam Merz <adammerz <at> hotmail.com> wrote:
<snip> I'm not sure if this is intentional and/or benign, but I thought it was worth mentioning. I've hosted the bjam output in case it's relevant:
[1] http://dl.dropbox.com/u/10282384/x86debug.txt [2] http://dl.dropbox.com/u/10282384/x86release.txt [3] http://dl.dropbox.com/u/10282384/x64debug.txt [4] http://dl.dropbox.com/u/10282384/x64release.txt
Has there been any resolution of this problem?
--Beman
Is this question directed at myself or Emil (or someone else)?
Anyone who knows the answer:-)
If myself, then has the 1.47 beta been repackaged since it was initially made available? I only have the .7z package from boost.cowic.de that I downloaded on the 21st.
boost.cowic.de boost-windows-2011-06-28.7z is the nightly snapshot. --Beman
On 29/06/2011 12:12, Beman Dawes wrote:
On Tue, Jun 28, 2011 at 2:27 PM, Adam Merz<adammerz@hotmail.com> wrote:
Beman Dawes<bdawes<at> acm.org> writes:
On Wed, Jun 22, 2011 at 1:32 PM, Adam Merz<adammerz<at> hotmail.com> wrote:
<snip> I'm not sure if this is intentional and/or benign, but I thought it was worth mentioning. I've hosted the bjam output in case it's relevant:
[1] http://dl.dropbox.com/u/10282384/x86debug.txt [2] http://dl.dropbox.com/u/10282384/x86release.txt [3] http://dl.dropbox.com/u/10282384/x64debug.txt [4] http://dl.dropbox.com/u/10282384/x64release.txt
Has there been any resolution of this problem?
--Beman
Is this question directed at myself or Emil (or someone else)?
Anyone who knows the answer:-)
Answer is no for both Release and Trunk. KTC
On Wed, Jun 29, 2011 at 4:12 AM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Jun 28, 2011 at 2:27 PM, Adam Merz <adammerz@hotmail.com> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
On Wed, Jun 22, 2011 at 1:32 PM, Adam Merz <adammerz <at> hotmail.com> wrote:
<snip> I'm not sure if this is intentional and/or benign, but I thought it was worth mentioning. I've hosted the bjam output in case it's relevant:
[1] http://dl.dropbox.com/u/10282384/x86debug.txt [2] http://dl.dropbox.com/u/10282384/x86release.txt [3] http://dl.dropbox.com/u/10282384/x64debug.txt [4] http://dl.dropbox.com/u/10282384/x64release.txt
Has there been any resolution of this problem?
I'm attaching a patch which should fix the problem for now. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 29/06/2011 20:12, Emil Dotchevski wrote:
On Wed, Jun 29, 2011 at 4:12 AM, Beman Dawes<bdawes@acm.org> wrote:
Has there been any resolution of this problem?
I'm attaching a patch which should fix the problem for now.
Well, it does cause the errors to go away but it's not so much a fix as comment everything out. :D If you're going to do that, might as well completely revert the new codes than telling bjam to prepare to build nothing. KTC
On Wed, Jun 29, 2011 at 2:05 PM, KTC <ktc@ktchan.info> wrote:
On 29/06/2011 20:12, Emil Dotchevski wrote:
On Wed, Jun 29, 2011 at 4:12 AM, Beman Dawes<bdawes@acm.org> wrote:
Has there been any resolution of this problem?
I'm attaching a patch which should fix the problem for now.
Well, it does cause the errors to go away but it's not so much a fix as comment everything out. :D If you're going to do that, might as well completely revert the new codes than telling bjam to prepare to build nothing.
This is not all of the new stuff. If someone cares, I can explain why commenting this out instead of deleting the Jamfile is better for now -- it is only temporary until I write the Jamfiles correctly (it is a bit tricky.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (19)
-
Adam Merz -
Antony Polukhin -
Barend Gehrels -
Beman Dawes -
Christoph Duelli -
Daniel James -
Emil Dotchevski -
Jeremiah Willcock -
Jeroen Habraken -
Jürgen Hunold -
KTC -
Lars Viklund -
Lior Kogan -
Matus Chochlik -
Rene Rivera -
Robert Ramey -
Tal Agmon -
Vicente Botet -
Vladimir Prus