This looks like a build configuration issue. Make sure you can compile, link and run the test programs. Robert Ramey "Jeffrey Holle" wrote in message news:cp2arc$mbf$1@sea.gmane.org...

Somethings I forgot to mention, I'm using gcc v3.4.3 with the boost 1.32.0 release. I've recompiled the boost_serialization.a multiple times with no affect on these link errors.

Jeffrey Holle wrote:

...

Now I'm experiencing link problems in attempting to apply boost.serialization to my application.

I can avoid them by commenting out the bodies of all my serialize methods. If I leave a simple serialize method intact, I can run the sucessfully linked application and produce an archive file.

I am linking to this serialization library:

$BOOST_ROOT/bin/boost/libs/serialization/build/libboost_serialization.a/gcc/ release/runtime-link-static/boost_serialization.a

...

With all serialization uncommented, I get the following link errors:

../../install/libUMLModel.so: undefined reference to

`boost::archive::detail::archive_pointer_iserializer::archive_pointer_iserializer(boost::serialization::extended_type_i nfo

...

const&)' ../../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_upcast(boost::serialization::extended_type_info

...

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::detail::archive_pointer_iserializer::find(boost::serialization::extended_type_info

...

const&)' ../../install/libUMLModel.so: undefined reference to

`boost::archive::basic_binary_iprimitive

...

std::basic_istream

...

::load(std::basic_string&)' ../../install/libUMLModel.so: undefined reference to

`boost::archive::detail::basic_iarchive::register_basic_serializer(boost::ar chive::detail::basic_iserializer

...

const&)' ../../install/libUMLModel.so: undefined reference to `boost::archive::detail::basic_iarchive::next_object_pointer(void*)' ../../install/libUMLModel.so: undefined reference to `typeinfo for boost::archive::detail::basic_iarchive' ../../install/libUMLModel.so: undefined reference to `boost::archive::detail::basic_iarchive::load_pointer(void*&, boost::archive::detail::basic_pointer_iserializer const*, boost::archive::detail::basic_pointer_iserializer const* (*)(boost::serialization::extended_type_info const&))' ../../install/libUMLModel.so: undefined reference to `boost::archive::detail::basic_iarchive::load_object(void*, boost::archive::detail::basic_iserializer const&)'

What is the solution?

Robert Ramey wrote:

This looks like a build configuration issue. Make sure you can compile, link and run the test programs.

I had to modify the Jamfile in the serialization/example directory to accomplish building the examples, but I can build all (10) without trouble. In the serialization/test directory, I did "bjam clean" and then "bjam" The results included 214 "**passed**" messages, with nothing other than some compilation warnings to indicate an error. Be aware of my original message, I can successfully build and run a trivial example, one that contains only one serialize method. The problem developes when I attempt to active all of my serialize methods. My application has 34 all together. These are not templated, so there is one for input and one for output in each module.

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

"Jeffrey Holle" wrote in message news:cp583r$djn$1@sea.gmane.org...

I'm building a shared library.

This could be an issue. I'm currently implementing the auto-link facility to permit serialization library to be built as a DLL (the windows equivalent of a shared library) as well as a unix shared library. I've had to make some changes to make this work correctly. I don't remember what they were for now. Right now I'm bogged down in making the test and test reporting work for all the combinations that I will be able to build and test. So the job is not done. There are other issues when serializing types defined in other shared libraries and/or DLLS which are dynamically loaded. I have also addressed these - but as said I'm bogged down in getting my test setup fixed to my requirements. Robert Ramey