Re: [Boost-users] Boost.DLL formal review is ending soon - submit your reviews

Subject: Re: [Boost-users] Boost.DLL formal review is ending soon - submit your reviews
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2015-07-15 03:16:38

2015-07-13 21:07 GMT+03:00 Lee Clagett <forum_at_[hidden]>:

> 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