Boost C++ Libraries: Ticket #12336: Add Hint to BOOST_ALL_DYN_LINK=1 to serialization library

Robert Ramey — Tue, 01 Nov 2016 22:24:43 GMT

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@… — Wed, 02 Nov 2016 06:25:45 GMT

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

status changed; resolution set

Robert Ramey — Wed, 02 Nov 2016 19:34:18 GMT

status new → closed
resolution → wontfix

"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