
Douglas Gregor wrote:
1. The Serialization lib is failing many of its regression tests. We need to get these under control.
Summary of pending issues related to the seriaization library. Issues I can deal with a) msvc - serialization of exported pointers broke due to a recent change made to better handle some aspects of abstract base classes. b) TRU64 and CW - experiments are on-going in getting compilers instanticiate code not explicitly referenced. Due to the efforts of Rene Rivera, much progress has been made on CW but there is still a way to go. Issues that I can't deal with a) cw- 9_5- darwin - this fails in execution of all DLL versions of the library. b) acc - looks pretty good - but all DLL versions fail c) gcc- 2.95.3- stlport- 4.6.2- linux doesn't seem to have SPIRIT_ROOT set and pointing to a copy of spirit 1.6x. The serialization library and tests are therefore skipped resulting in white space in the table d) gcc (Beman) I presume this is cygwin which doesn't support wide character i/o. If this toolset name were changed to gcc-cygwin, these tests would be skipped and results would show as white space. e) como- 4_3_3- vc7_1 - There is some sort of conflict between the serialization library and the test library. The results in both instantiating code for streams which results in a linkage error. I made an inquiry to Commeau and here is the response I get: "When templates are involved, often you need to do a closure on a library, using the --prelink_objects command line option: como -c blah1.cpp como -c blah2.cpp como --prelink_objects blah1.obj blah2.obj This can be done "directly" as well: como --prelink_objects blah1.cpp blah2.cpp This will leave specific object files as owners of specific instantiations. Therefore, when some libraries have dependencies on other libraries, they may have to be included in the closure request: como --prelink_objects blah1.obj blah2.obj theOtherLibrary.lib That said, in your case your getting an error from a routine in libcomo, or from some similar standard library. If libcomo, has it been built ok, and w/o any errors? Are there any .lib file in your libcomo directory? What does the file 'makeout' contain?" I'm still digesting this. f) RudbekAssociates results show a recent date/time but contain error message which refer to functions that are no longer in the library. I believe that something needs to be refreshed here. g) last time I checked SunOS, DMC and vacpp failed to build the library due to failures in code outside the serialization library. Generally I have marked these compilers as not usable. Robert Ramey