2015-07-13 21:07 GMT+03:00 Lee Clagett
I'm sure some will find this library would be useful; I worked on a project that implemented the factory example in a Windows & Linux environment. Unfortunately, these types of systems are also brittle (ABI). Is there a way to add a symbol that acts similar to the soname automatically? If group A provides a boost::dll plugin with an explicit version, and then group B doesn't request that version when loading some symbol from the plugin, boost::dll automatically fails in all load functions. This way a provider of a plugin can force the user of a plugin to think about potential ABI problems through the boost::dll interface.
I've been playing around with Boost.DLL in my toy project and solved that problem in a nasty way; libcore.so - contains all the functionality to load libraries and additionally contains a `BOOST_SYMBOL_EXPORT int my_library_version_1_2_7345` plugin1.so - plugin and `BOOST_SYMBOL_IMPORT int my_library_version_1_2_7345`. Links with libcore.so plugin2.so - plugin and `BOOST_SYMBOL_IMPORT int my_library_version_1_2_7345`. Links with libcore.so main - program itself. Linked with libcore.so, uses libcore.so functions to load plugins/libraries functions dynamically. Now, if libcore.so attempts to load library with different version (for example with `BOOST_SYMBOL_IMPORT int my_library_version_1_0_0001`), then loading a plugin fails. because of undefined symbol. Otherwise symbol is found in libcore.so and libraru loading succeeds.
The use-case might be too narrow though, especially since the importer of boost::dll should really think about these issues. However, is it worth discussing ABI issues a little more in the documentation, or at least point to a good external resource (the Drepper paper)? Someone who finds this library may be less knowledgeable of such issues.
This is hard to do it portably on library level. It's better to have that recipe described somewhere so that users could experiment with that. -- Best regards, Antony Polukhin