Add Hint to BOOST_ALL_DYN_LINK=1 to serialization library

[georg@…]

When you serialize a class over a pointer and the class is defined in a DLL, you need to register the key via BOOST_EXPORT_CLASS(xyz).

But when you link static, you get two distinct serialization registries (extended_type_info) and the main executable cant serialize/deserialize the class in the DLL.

When you compile with BOOST_ALL_DYN_LINK=1 and dynamicaly link to the boost libs, this ensures that there is just one registry (extended_type_info).

So i would add this hint in the "Tips & Tricks" section or in the page of the derived classes.

BOOST_ALL_DYN_LINK=1 is important for the serialization. This ensures that there is just one extended_type_info registry. Otherwise the main executable cant de/serialize the objects in the DLL/so file.

[Robert Ramey]

Hmmm - I believe that if you link static you should get only one registry.

"When you compile with BOOST_ALL_DYN_LINK=1 and dynamicaly link to the boost libs, this ensures that there is just one registry (extended_type_info)."

sound like you're using static linking and dynamic linking to deserialize. I don't see why that would be a problem, but I'd have to think about it (a lot) to really be sure. But I don't know if that's what you actually mean either.

[georg@…]

Dear Robert,

yes, if i link all static (without explicit loaded plugin dll) i get one registry.

We use a lot of virtual base classes in the executable and the implementations in dlls. The plugin is explicit loaded via "LoadLibrary()" and the instance is created via an exported and "GetProcAddress()ed" function.

If i link static, the executable and the plugin dll, i get two registries. You can verify this if you check what extended_type_info object the BOOST_EXPORT_KEY_IMPLEMENT calls. I checked the this pointers of it.

If i link all, the executable and the plugin with BOOST_ALL_DYN_LINK=1, then there is just one registry.

A coworker run into this problem and got unregistered_class exceptions and he could not figure out why it occured. I knew this from the past and could help him. So i thought, why not add a hint in the documentation.

Georg

[Robert Ramey]

"If i link static, the executable and the plugin dll, i get two registries. You can verify this if you check what extended_type_info object the BOOST_EXPORT_KEY_IMPLEMENT calls. I checked the this pointers of it.

If i link all, the executable and the plugin with BOOST_ALL_DYN_LINK=1, then there is just one registry."

Your idea to add it to the docs is not a bad one. I'll consider it. But the issue is much broader than that. In C++ if one builds with static libraries then link to a DLL, you can easily create a problem. This is because when one builds the app with static library, the linker then added all the C++ library stuff as static modules. Then you call a DLL. But the DLL -also written in C++ will also cal C++ library functions. Then either of the following occurs. If the DLL is linked statically, you've got the C++ function twice in the code. This is a problem for things like strtok and other stuff which carry an internal state. Or the DLL links to a C++ runtime and now you've go two different versions of the C++ library in your code. You can manage all this if you're careful - but its way too easy to create a failure which is almost impossible to find - as you've found out.

So if you want write a good explanation of all this, I'll consider adding it to the tips and tricks section.

Robert Ramey