Re: [boost] [config] really, really sticky issue with BOOST_SYMBOL_IMPORT

Subject: Re: [boost] [config] really, really sticky issue with BOOST_SYMBOL_IMPORT
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-10-10 14:47:02

On 10/10/18 7:37 AM, Robert Ramey via Boost wrote:
> For many, many years we've built the Boost serialization library with 
> the macros for BOOST_SYMBOL_IMPORT and BOOST_SYMBOL_EXPORT set according 
> to the instructions included in the boost/config documentation written 
> by John Maddock.  These set attributes for creating and using DLLS for 
> windows and (used to) resolve to nothing on other systems.  So far so good.
> 
> At some point things changed for gcc compilers.  Now it seems that 
> BOOST_SYMBOL_IMPORT resolves to nothing and BOOST_SYMBOL_EXPORT resolves 
> to : __attribute__ ((visibility("default"))) and BOOST_SYMBOL_IMPORT 
> still resolves to nothing.  OK - this has never been a problem.

The definition of BOOST_SYMBOL_IMPORT haven't changed since 2010, so 
it's not what changed.

Indeed, you don't need BOOST_SYMBOL_IMPORT to be defined to 
__attribute__ ((visibility("default"))) because imported symbols are not 
defined in your code; they are defined in the shared library, which had 
them marked with BOOST_SYMBOL_EXPORT.

> Now we have an extremely subtle issue which appears on linux systems 
> with gcc. It's related to sequence of shared library loading and 
> unloading.  It shows up as a bunch of test failures for the test named 
> test_exported_dll.  A very astute user has determined that this can be 
> "fixed" by defining BOOST_SYMBOL_IMPORT as __attribute__ 
> ((visibility("default"))) as well.  Question. should config/gcc be 
> updated in this way?  Also is it possible that this "fix" is just a 
> fluke unrelated to the real source of the problem?

No, this is not a correct fix, IMO. The fact that changing 
BOOST_SYMBOL_IMPORT to __attribute__ ((visibility("default"))) fixes the 
problem implies that the symbols in question are probably not correctly 
marked in the first place. Or the symbols might be defined in multiple 
modules while it is not intended to be so.

If a symbol is defined in a single shared library and not defined 
anywhere else then it should be marked with BOOST_SYMBOL_EXPORT when 
building that library and BOOST_SYMBOL_IMPORT (which expands to nothing 
on Linux) everywhere else.

If a symbol is supposed to be defined in multiple modules and still has 
to be exported from each one of them so that at runtime only one copy is 
picked by the runtime loader, then you mark the symbol with 
BOOST_SYMBOL_VISIBLE. Note that this behavior cannot be achieved on 
Windows, so if it matters you should design the code so that the symbol 
is exported from only one shared library and use 
BOOST_SYMBOL_IMPORT/EXPORT on it.