boost serialization calls wrong guild()

[Xiaolong <xwu622@…>]

I have a serializaiton program that serializes over 600 classes. During the singleton initialization, the program should call the guid() function defined in macro BOOST_CLASS_EXPORT_GUID in export.hpp. But about 40% of class singletons call the dummy guild() function defined in extened_type_info.hpp:

template<class T>
struct guid_defined : boost::mpl::false_ {};
template<class T>
inline const char * guid(){
return NULL;
}

This causes m_key=NULL, and later causes "unregistered class" error for multiple inheritence classes.

The following two lines are ajacent in the same file. The first calls the dummy guid(), the second calls the macro guid().
BOOST_CLASS_EXPORT_GUID(CffCDOQuote, "CffCDOQuote")
BOOST_CLASS_EXPORT_GUID(boost::shared_ptr< CffCDOQuote >, "CffCDOQuotePtr")

I am working in Windows 7, VC++ 9.0 and Boost 1.44.0.

I tried all possible project settings of optimization and runtime, got no luck.

It is difficult to create a simple test case. I will be happy to provide more info if needed.

Thanks

Xiaolong

[Robert Ramey]

it looks that perhaps the serialization code for the derived classes are not getting explicitly instantiated.

Check the documentation for BOOST_CLASS_EXPORT_KEY and BOOST_CLASS_EXPORT_IMPL.

Also look at the test_dll_exported, test_dll_plugin and test_dll_simple.

Also look at demo_polymorphic and maybe demo_pimpl.

I think I'm right about this so I'm going to close this item for now.

Robert Ramey

[Xiaolong <xwu622@…>]

Here are more details about this issue. I have 6 analytic libraries. I create a static library of boost-serialization wrapper for each of them. Then I link the 6 static serialization libraries into a dynamic library.

I cannot use dynamic wrapper, because there would be one copy of singleton<detail::ktmap> in each wrapper.

I found a workaround: linking directly to the .obj files, instead of linking to the 6 static library wrappers, when link the dynamic library.

In summary: the class hierarchy tree map cannot across dll boundary. That makes it difficult to use boost-serialization to large scale projects.

Having to link all serialization code into a single dll also caused errors like "file size exceeded 1G limit" (on linux), "the number of symbols exceeded 65535 limit" (on Windows).

[anonymous]

"I have 6 analytic libraries. I create a static library of boost-serialization wrapper for each of them. Then I link the 6 static serialization libraries into a dynamic library."

This is known to be a risky operation. Each static library will include static functions from the C runtime library which will be included in the dynamic library when it is made. If the main program is linked dynamically with the c runtime library, there will be different versions for the same code in the DLLS and the main line. This will violate the ODR. The problem is compounded when the main line is built with older DLLS. I would recommend the following:

Build all the DLLS with the dynamic version of the C Runtime library and other tools like the serialization library.

Build the Mainline with dynamic linking of libraries.

This will gain you the following advantages:

a) Only ONE version of every routine in your code - eliminates confusion and potential for weird untraceable errors. b) With a little bit of work, you can load the DLLS "on demand" so they don't even get loaded when the main line doesn't use them. This is very, very useful for polymorphic types. An example is that one could have a complex mainline application which uses serialization library archives - but only through the polymorphic interfaces. When you use a new/updated archive/serialization code, it can be used without even re-compiling the mainline! c) The code body to be shipped to the customer is smaller as it has no redundancies.

and a disadvantage

a) you have to ship the MS C runtime DLL along with your product.

So, try building everything for dynamic linking and see if it helps.

Robert Ramey