[1.41][serialization] MSVC 9 crashes on compilation
Hi, I'm building the release branch on MSVC 9 + STLPort 5.1.5. The compiler crashes when compiling Boost.Serialization (more precisely, the xml_wgrammar.cpp file). The command line I use is as follows: bjam.exe -j 2 --toolset=msvc variant=release link=shared threading=multi runtime-link=shared optimization=speed inlining=full stdlib=stlport --without-mpi --without-wave --without-python --without-graph stage Does anyone else have these problems?
Andrey Semashev-2 wrote:
Hi,
I'm building the release branch on MSVC 9 + STLPort 5.1.5. The compiler crashes when compiling Boost.Serialization (more precisely, the xml_wgrammar.cpp file). The command line I use is as follows:
bjam.exe -j 2 --toolset=msvc variant=release link=shared threading=multi runtime-link=shared optimization=speed inlining=full stdlib=stlport --without-mpi --without-wave --without-python --without-graph stage
Does anyone else have these problems?
Same here using VC9 with its own std lib. Looks like it might just have been broken - rolling boost/archive/iterators/xml_unescape.hpp back to the previous revision allows it to compile. -- View this message in context: http://old.nabble.com/-1.41--serialization--MSVC-9-crashes-on-compilation-tp... Sent from the Boost - Dev mailing list archive at Nabble.com.
Richard Webb wrote:
Andrey Semashev-2 wrote:
Hi,
I'm building the release branch on MSVC 9 + STLPort 5.1.5. The compiler crashes when compiling Boost.Serialization (more precisely, the xml_wgrammar.cpp file). The command line I use is as follows:
bjam.exe -j 2 --toolset=msvc variant=release link=shared threading=multi runtime-link=shared optimization=speed inlining=full stdlib=stlport --without-mpi --without-wave --without-python --without-graph stage
Does anyone else have these problems?
Same here using VC9 with its own std lib.
Looks like it might just have been broken - rolling boost/archive/iterators/xml_unescape.hpp back to the previous revision allows it to compile.
Confirmed. The fix is trivial: change line 53 from typedef BOOST_DEDUCED_TYPENAME this_t::value_type value_type; to typedef BOOST_DEDUCED_TYPENAME super_t::value_type value_type; Beman, Robert, can we apply this fix before the 1.41 release is out?
On Sun, Nov 15, 2009 at 7:58 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Richard Webb wrote:
Same here using VC9 with its own std lib.
Looks like it might just have been broken - rolling boost/archive/iterators/xml_unescape.hpp back to the previous revision allows it to compile.
Confirmed. The fix is trivial: change line 53 from
typedef BOOST_DEDUCED_TYPENAME this_t::value_type value_type;
to
typedef BOOST_DEDUCED_TYPENAME super_t::value_type value_type;
Beman, Robert, can we apply this fix before the 1.41 release is out?
Seems to me we should fix this. Robert? --Beman
I made HUGE blunder. I accidently commited changes to the release branch when I meant to commit them to the trunk. I'm on my way out the door now. I'll revert them when I get back. I'm really, really sorry. Robert Ramey Beman Dawes wrote:
On Sun, Nov 15, 2009 at 7:58 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Richard Webb wrote:
Same here using VC9 with its own std lib.
Looks like it might just have been broken - rolling boost/archive/iterators/xml_unescape.hpp back to the previous revision allows it to compile.
Confirmed. The fix is trivial: change line 53 from
typedef BOOST_DEDUCED_TYPENAME this_t::value_type value_type;
to
typedef BOOST_DEDUCED_TYPENAME super_t::value_type value_type;
Beman, Robert, can we apply this fix before the 1.41 release is out?
Seems to me we should fix this. Robert?
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, Nov 15, 2009 at 11:23 AM, Robert Ramey <ramey@rrsd.com> wrote:
I made HUGE blunder.
I accidently commited changes to the release branch when I meant to commit them to the trunk. I'm on my way out the door now. I'll revert them when I get back.
I'm really, really sorry.
No sweat. I messed up, too - I should have detected that some of the release tests were stale and waited until they cycled. I see that the changes have been reverted, so will generate release candidates again tomorrow once the fresh tests cycle. The critical point, however, is that we did follow the procedure of asking for independent verification that the release candidate builds OK. Many thanks to Andrey for detecting the problem, and Richard for confirming it! --Beman
Note that SVN permits one to "lock" the branch for commits. This might be useful during "critical" periods to catch these kinds of errors. Robert Ramey Beman Dawes wrote:
On Sun, Nov 15, 2009 at 11:23 AM, Robert Ramey <ramey@rrsd.com> wrote:
I made HUGE blunder.
I accidently commited changes to the release branch when I meant to commit them to the trunk. I'm on my way out the door now. I'll revert them when I get back.
I'm really, really sorry.
No sweat. I messed up, too - I should have detected that some of the release tests were stale and waited until they cycled. I see that the changes have been reverted, so will generate release candidates again tomorrow once the fresh tests cycle.
The critical point, however, is that we did follow the procedure of asking for independent verification that the release candidate builds OK.
Many thanks to Andrey for detecting the problem, and Richard for confirming it!
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, Nov 15, 2009 at 8:11 PM, Robert Ramey <ramey@rrsd.com> wrote:
Note that SVN permits one to "lock" the branch for commits. This might be useful during "critical" periods to catch these kinds of errors.
As an experiment, I've locked branches/release while I build a new release candidate. One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git? --Beman
Hi, On Mon, Nov 16, 2009 at 10:25 PM, Beman Dawes <bdawes@acm.org> wrote:
As an experiment, I've locked branches/release while I build a new release candidate.
One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?
I am a Bazaar user, not a Git user, so pardon my ignorance: is there even an equivalent operation for Git? I would think that one would just use a local branch and thus be oblivious to any further changes committed, except when pulling from the remote release branch intentionally. Regards, Eugene
Eugene Wee wrote:
Hi,
On Mon, Nov 16, 2009 at 10:25 PM, Beman Dawes <bdawes@acm.org> wrote:
As an experiment, I've locked branches/release while I build a new release candidate.
One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?
I am a Bazaar user, not a Git user, so pardon my ignorance: is there even an equivalent operation for Git? I would think that one would just use a local branch and thus be oblivious to any further changes committed, except when pulling from the remote release branch intentionally.
You're right, there is no such operation, the distributed architecture makes it unnecessary. -t
On Mon, Nov 16, 2009 at 9:41 AM, troy d. straszheim <troy@resophonic.com> wrote:
Eugene Wee wrote:
Hi,
On Mon, Nov 16, 2009 at 10:25 PM, Beman Dawes <bdawes@acm.org> wrote:
As an experiment, I've locked branches/release while I build a new release candidate.
One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?
I am a Bazaar user, not a Git user, so pardon my ignorance: is there even an equivalent operation for Git? I would think that one would just use a local branch and thus be oblivious to any further changes committed, except when pulling from the remote release branch intentionally.
You're right, there is no such operation, the distributed architecture makes it unnecessary.
The point isn't always just for the release manager to be oblivious to further changes, it may also be to prevent those further changes to the master server (or whatever Git calls it) in the first place. I probably don't understand how the master server is updated and administered in a distributed environment. That will probably become obvious if I do some more reading. Thanks, --Beman
Beman Dawes wrote:
On Mon, Nov 16, 2009 at 9:41 AM, troy d. straszheim <troy@resophonic.com> wrote:
Eugene Wee wrote:
Hi,
On Mon, Nov 16, 2009 at 10:25 PM, Beman Dawes <bdawes@acm.org> wrote:
As an experiment, I've locked branches/release while I build a new release candidate.
One problem: It took just one minute shy of two hours to apply the lock. That's no fun. Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git? I am a Bazaar user, not a Git user, so pardon my ignorance: is there even an equivalent operation for Git? I would think that one would just use a local branch and thus be oblivious to any further changes committed, except when pulling from the remote release branch intentionally. You're right, there is no such operation, the distributed architecture makes it unnecessary.
The point isn't always just for the release manager to be oblivious to further changes, it may also be to prevent those further changes to the master server (or whatever Git calls it) in the first place.
Yes, exactly.
I probably don't understand how the master server is updated and administered in a distributed environment. That will probably become obvious if I do some more reading.
I found Linus Torvalds' Google Tech Talk enlightening: http://www.youtube.com/watch?v=4XpnKHJAok8 -t
Beman Dawes wrote:
On Sun, Nov 15, 2009 at 8:11 PM, Robert Ramey <ramey@rrsd.com> wrote:
Note that SVN permits one to "lock" the branch for commits. This might be useful during "critical" periods to catch these kinds of errors.
As an experiment, I've locked branches/release while I build a new release candidate.
One problem: It took just one minute shy of two hours to apply the lock. That's no fun.
Wow. Presumably lock of entire branch is not the primary use case for 'svn lock'. You can actually do: svn cp ^/branches/release ^/branches/1_41_0_final svn sw ^/branches/1_41_0_final as the first step in release preparation. That's likely to be much faster. (The ^ syntax works only if you're in a working copy).
Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?
Well, given that git does not have locks, it's a trick question. You can write a hook to disable commits to a specific branch, and install that hook in no time -- but you can do the same in subversion (or use path-based authorization). In both cases, you need direct access to server. - Volodya
On Mon, Nov 16, 2009 at 9:39 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Beman Dawes wrote:
On Sun, Nov 15, 2009 at 8:11 PM, Robert Ramey <ramey@rrsd.com> wrote:
Note that SVN permits one to "lock" the branch for commits. This might be useful during "critical" periods to catch these kinds of errors.
As an experiment, I've locked branches/release while I build a new release candidate.
One problem: It took just one minute shy of two hours to apply the lock. That's no fun.
Wow. Presumably lock of entire branch is not the primary use case for 'svn lock'. You can actually do:
svn cp ^/branches/release ^/branches/1_41_0_final svn sw ^/branches/1_41_0_final
as the first step in release preparation. That's likely to be much faster.
Interesting. But it is a bit more complex than that due to the need to do separate Unix line ending and Windows line ending exports. I'll explore further.
(The ^ syntax works only if you're in a working copy).
I'm only beginning to wrap my mind around the ^ syntax. It seems quite useful.
Presumably it will take another two hours to unlock it. As an aside, I wonder how long the equivalent operation would have taken with Git?
Well, given that git does not have locks, it's a trick question. You can write a hook to disable commits to a specific branch, and install that hook in no time -- but you can do the same in subversion (or use path-based authorization). In both cases, you need direct access to server.
Thanks, --Beman
On 11/16/2009 09:48 AM, Beman Dawes wrote:
Interesting. But it is a bit more complex than that due to the need to do separate Unix line ending and Windows line ending exports. I'll explore further.
Can the line-ending adjustment not be done as part of the packaging process ? I would expect there are other advantages for building releases / packages out of the very same source tree... Stefan -- ...ich hab' noch einen Koffer in Berlin...
OK - I've reverted the changes from the release branch and commited them to the trunk as I originally intended. At least I think I did as SVN is a little unwieldy for this operation and always leaves me wondering if I got it right. Robert Ramey Beman Dawes wrote:
On Sun, Nov 15, 2009 at 11:23 AM, Robert Ramey <ramey@rrsd.com> wrote:
I made HUGE blunder.
I accidently commited changes to the release branch when I meant to commit them to the trunk. I'm on my way out the door now. I'll revert them when I get back.
I'm really, really sorry.
No sweat. I messed up, too - I should have detected that some of the release tests were stale and waited until they cycled. I see that the changes have been reverted, so will generate release candidates again tomorrow once the fresh tests cycle.
The critical point, however, is that we did follow the procedure of asking for independent verification that the release candidate builds OK.
Many thanks to Andrey for detecting the problem, and Richard for confirming it!
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Nov 16, 2009 at 12:45 AM, Robert Ramey <ramey@rrsd.com> wrote:
OK - I've reverted the changes from the release branch and commited them to the trunk as I originally intended. At least I think I did as SVN is a little unwieldy for this operation and always leaves me wondering if I got it right.
The tests seem to have cleared, so that's a good sign. A refreshed release candidate should be available later today. Thanks, --Beman
participants (8)
-
Andrey Semashev -
Beman Dawes -
Eugene Wee -
Richard Webb -
Robert Ramey -
Stefan Seefeld -
troy d. straszheim -
Vladimir Prus