[Boost-users] Re: Link problems with boost.serialization

I certainly sympathize with your difficulties. I realize this does take a lot of time. And I do appreciate the effort your going through to make this work. We have had reports of lots of memory used and incredible long compile times when this combination is used. This might be related. question: are you compiling for release or debug. In some release configurations comilers are over zealous in eliminating code not referenced by name. Sometimes its helpful to me to use the unix strings command to display all th displayable stuff in the library or object module. Some linkers may be sensitve to the order in which modules are listed. Are you building with bjam or with your own make or ? Its possible that bjam includes some command line switches or something that's different than you are. In fact, its possible that whatever is sending the command to the OS is actually truncating it - at after about 14 modules. You might try building a library out of all the modules in your library. Then link the main module with your application library. This will keep the command line shorter. It also is useful to automatically eliminate "dead code" in a large application (which it seems your's might be). These are just random ideas - I have no idea if any of these might be useful. I'm real questioning whether this is an issue with serialization at all. Robert Ramey "Jeffrey Holle" wrote in message news:cp4tp5$c84$1@sea.gmane.org...

I've done some time consuming experiementing with situation. What I find is I can cut the number of link errors to: ../../install/libUMLModel.so: undefined reference to

`boost::serialization::void_downcast(boost::serialization::extended_type_inf o

const&, boost::serialization::extended_type_info const&, void const*, bool)' ../../install/libUMLModel.so: undefined reference to `boost::serialization::void_cast_detail::void_caster::self_register()' ../../install/libUMLModel.so: undefined reference to `boost::archive::basic_binary_iprimitive

...

::load(std::basic_string&)'

I believe that in your case we suggested making a new type "tracked_string" in order to take into consideration that strings are considered primitive types for serialization purposes and are therefore generally not serialized as pointers. I wonder why the above is getting called.

by commenting out the input serialize method in 14 of 17 modules. The problem doesn't seem to be related to specific modules, instead its the number of them. I say this because I have avoided the majority of linker errors by commenting out 3 different modules, all of them being about the 14th module getting such treatment.

Have never seen such behavior out of a compiler/linker. It is concerning!

welcome to modern C++ programming !! Robert Ramey