On 10/10/2018 17:37, Robert Ramey wrote:

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.

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?

While I know next to nothing about how Linux DSOs work, my reading of https://gcc.gnu.org/wiki/Visibility suggests that you're supposed to specify the same visibility level for both definition and usage of any given symbol. (See in particular the example code in the step-by-step guide, and some of the admonishments against using different visibility in the section on exceptions.)

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.