[1.38.0] [Integer] Library in inconsistent state
The Integer library is in an inconsistent state. Release regression tests are failing on all platforms. Trunk tests are failing on many platforms, too. I finally got a reply to a private query to Daryle Walker, and he is not going to be able to do any work on the library for the present. Thus we need someone to put the library into a consistent and stable state for the 1.38.0 release. That means either fix whatever ails it or, if that isn't possible, revert until a working state is reached. Volunteers needed! --Beman
The Integer library is in an inconsistent state. Release regression tests are failing on all platforms. Trunk tests are failing on many platforms, too.
I finally got a reply to a private query to Daryle Walker, and he is not going to be able to do any work on the library for the present.
Thus we need someone to put the library into a consistent and stable state for the 1.38.0 release. That means either fix whatever ails it or, if that isn't possible, revert until a working state is reached.
Volunteers needed!
I'll try and take a look, but it'll be tomorrow at the earliest now.... and then we'll have to wait for the results to cycle and then... etc John.
John Maddock wrote:
I'll try and take a look, but it'll be tomorrow at the earliest now.... and then we'll have to wait for the results to cycle and then... etc
I looked at it, before I saw a mail from John. There is only one Boost.Integer test failing on release branch: integer_mask_test.cpp. The failure is linking failure with undefined symbol for main (or _main on some platforms). Inclusion of <boost/test/minimal.hpp> instead of #define BOOST_INCLUDE_MAIN #include <boost/test/test_tools.hpp> fixes the problem -- see patch below. Tested on HP-UX with aC++ and GCC. If it looks like a correct fix, I can commit it to release branch. The test is very different in trunk and release branch and trunk does not have this linking problem. Thanks, Boris Index: test/integer_mask_test.cpp =================================================================== --- test/integer_mask_test.cpp (revision 50929) +++ test/integer_mask_test.cpp (working copy) @@ -10,8 +10,7 @@ // Revision History // 23 Sep 2001 Initial version (Daryle Walker) -#define BOOST_INCLUDE_MAIN -#include <boost/test/test_tools.hpp> // for main +#include <boost/test/minimal.hpp> // for main #include <boost/cstdlib.hpp> // for boost::exit_success #include <boost/integer/integer_mask.hpp> // for boost::high_bit_mask_t, etc.
On Sat, Jan 31, 2009 at 1:33 PM, Gubenko, Boris <boris.gubenko@hp.com> wrote:
John Maddock wrote:
I'll try and take a look, but it'll be tomorrow at the earliest now.... and then we'll have to wait for the results to cycle and then... etc
I looked at it, before I saw a mail from John. There is only one Boost.Integer test failing on release branch: integer_mask_test.cpp. The failure is linking failure with undefined symbol for main (or _main on some platforms).
Inclusion of <boost/test/minimal.hpp> instead of
#define BOOST_INCLUDE_MAIN #include <boost/test/test_tools.hpp>
fixes the problem -- see patch below. Tested on HP-UX with aC++ and GCC.
If it looks like a correct fix, I can commit it to release branch.
Sure. Try it.
The test is very different in trunk and release branch and trunk does not have this linking problem.
That's a worry. Is that an indication trunk needs to be merged into release? --Beman
Beman Dawes wrote:
Gubenko, Boris wrote:
If it looks like a correct fix, I can commit it to release branch.
Sure. Try it.
Done: <http://svn.boost.org/trac/boost/changeset/50935>
The test is very different in trunk and release branch and trunk does not have this linking problem.
That's a worry. Is that an indication trunk needs to be merged into release?
If you are talking about Boost.Integer library as a whole, not just about test fixed in changeset above, I don't know if the library is ready to be merged into the release. The library fails on many platforms on the trunk, including at least one release platform -- RW_WinXP_VC10 -- and the failures are not a link failure, which was the case on the release branch, but compilation errors. Thanks, Boris
participants (3)
-
Beman Dawes -
Gubenko, Boris -
John Maddock