Boost C++ Libraries: Ticket #6899: boost serialization calls wrong guild()

status changed; resolution set

Robert Ramey — Sun, 15 Jul 2012 20:16:23 GMT

status new → closed
resolution → invalid

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

Wed, 18 Jul 2012 14:46:37 GMT

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 — Wed, 18 Jul 2012 16:38:46 GMT

"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