Re: [boost] [1.33.0] Release status and updated timeline

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-07-08 00:14:44

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