[config] really, really sticky issue with BOOST_SYMBOL_IMPORT

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[config] really, really sticky issue with BOOST_SYMBOL_IMPORT

Boost - Dev mailing list
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.

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?

Note that this issue predates the recent change to make
-visibility=default which has, as one might expect, caused some issues.
I believe that this situation is unrelated.

Any help appreciated

Robert Ramey


reference:
https://github.com/boostorg/serialization/issues/104#issuecomment-416948110



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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.)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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?

Marking all imported and exported symbols as visible is the same as
setting global visibility to default.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost