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/serializat... 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/serializat... 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.