Boost logo

Boost :

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 list run by bdawes at, gregod at, cpdaniel at, john at