BTW, I had to remove the line <runtime-link>static

from the serialization/test/Jamfile to get the serializiation regression tests to link on my Linux machine. With g++ this was adding a -static which was apparently making it not find libstd++.

Hmm - no other gcc setup required this. Might this indicate that a tweak is necessary somewhere in config gcc/linux/mandrake/? Combination> This brings up an enduring mystery to me. Here is the key part of the jamfile from the build directory. lib boost_serialization : ## sources ## ../src/$(SOURCES).cpp : ## requirements ## <msvc><*><include>$(SPIRIT_ROOT) <borland><*><include>$(SPIRIT_ROOT) <borland-5.5.1><*><include>$(SPIRIT_ROOT) <borland-5.6.4><*><include>$(SPIRIT_ROOT) <sysinclude>$(BOOST_ROOT) <borland><*><cxxflags>"-w-8080 -w-8071 -w-8057" <msvc><*><cxxflags>-Gy <vc7><*><cxxflags>-Gy <vc7.1><*><cxxflags>-Gy <define>BOOST_TEST_NO_AUTO_LINK=1 : ## default-build <runtime-link>static <threading>single/multi ; I set default-build based on - I don't remember. I did horse around with it to get it in sync with with my MSVC IDE settings so I could inter-operate with MSVC IDE and bjam. This was very helpful for development. However, I really don't know that the build should even specify a default. Is this a default or does this override some other default build setting. That is if I just leave it out do I get no build at all or what. I did spend a little time perusing the included JAM files - but that's a mind bending exercise for "the rest of us". Would think I would just leave off the default build and let the upper level test/build build what it wants. Of course then is a silently morphing side-effect which I'm generally against. I don't believe the current test results displayed reflect the true current state of the serialization system. My results are: a) I've tested borland 5.5.1, 5.60, VC 6.0 with good results. Test results show failure for these platforms because the test setup doesn't make spirit 1.61 available which is a requirement for these platforms. b) I've tested VC 7.1 and gcc 3.3 under cygwin. VC 7.1 Is 100 % passing. Gcc under cygwin passes all tests except those requiring wide char i/o which is not supported on this platform. The table generates "fail" for these tests but that's not really accurate. c) Christophe has 100% passing on linux with gcc 3.4.1 . (gcc 3.4.0 had a show stopping issue which was easiest to address by upgrading. Unknown results: a) gcc 3.3.? on linux - I would expect 100% here. No results available pending the disk space issue. b) a) gcc 3.3.? on linux/mandrake - see above. Problems: a) Macos/Darwin. i) lots of tests passing ii) some confusion as to whether wide char i/o is supported here iii) a couple of run failures that need to be looked at with a debugger. Any volunteer? b) Comeau - a compiler issue with non-intrusive serialization. Set aside for now. c) IBM C++ - a comple issue re-interator traits. Since these tests are run very infrequently, its almost hopeless to address by trial and error. d) CWPro - compile issue - size_t not recognized? Clearly this needs an expert. e) Intel 7.1 - I had Intel 8.0 passing 100% before my eval license exprired. I can't fix this from my own machine. Needs an expert - or my own copy of intel 7.1. I'm sure this is easily fixable given that msvc 6.0 works pretty well. f) HP - very bizarre compilation error. I don't know but I suspect this would be the tip of an ice berg. Needs an expert. So - there you have it - In my view test results of the serialization library are not out of line from those of other platforms. Also the fact that there are more combinations tested perhaps brings to fore more issues than with other libraries. I would suggest we keep flogging away at it until just before the branch is made. That would be a good time to make a final decision. Robert Ramey