Re: [boost] Volunteers needed: clearing the last regressions for1.34

From: John Maddock (john_at_[hidden])
Date: 2006-10-17 14:03:45

Robert Ramey wrote:
>> The largest block is for the serialisation lib, at least one of the
>> errors appears to be due to http://support.microsoft.com/kb/883655
>> which requires splitting the .cpp file into smaller blocks as a
>> workaround.
>
> This is an old issue with the vc 6 compiler.  In the past I made some
> attempts to make these tests pass by jiggering the tests but it became
> clear that beyond a certain point started to "teach the test".
>
> So in this case, the test result should be interpreted as "this
> compiler can't support the serialization in this context" and
> hence the test is marked expected failure.  I believe that
> this is the correct thing to do and requires no further action.

It's failing with VC-7 as well, so the markup needs updating?

See 
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/serialization/test/test_reset_object_address.cpp

There are also 5 VC-6.5 failures with unresolved externals which aren't 
marked up, see 
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/serialization/test/test_reset_object_address.cpp 
for a typical example.

> FWIW - from time to time, these tests start passing spontaneously.
> Interesting - but still no call to action.
>
> In the latest test matrix, there are couple of failures that seem
> related to some aspect of the boost test system.  I don't believe
> these can be addressed from withing the serialization library
> test suite.

Hmm, I see this one http://tinyurl.com/ybxxnt which has an uncaught 
exception: "std::exception: invalid signature"

Do you know what's causing the exception to be thrown?

> The only real issues I see are:
>
> a) tweak of pending markup for new borland compiler which
> fails a test the previous one didn't - test_variant.

Yep, the problem symbol (_Stz) appears to be in <iosfwd> so whatever the 
issue is, it's not down to you.  Please mark them up so we don't waste time 
trying to track these down.

> b) (Not one the matrix) An issue with the correct macro
> to use with STLPort to signal/detect the existence of
> hashed containers. The code works - but the test fails.
> I've never been able to figure this out.

BOOST_HAS_HASH refers to the SGI style hashed containers, is that what 
STLport has (I would expect so).  Otherwise there's always:

defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)

Thanks,

John.