Re: [boost] [config] GCC symbol visibility across shared libraries

Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-20 11:36:54

Beman Dawes wrote:
> On Thu, May 20, 2010 at 10:21 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> >
> > Each dynamic library should define its own import/export
> > macro to adorn the symbols of that library that should be
> > exported/visible.  Those macros should be based upon
> > BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT and whether the
> > dynamic library is being built or used:
> >
> > #ifdef BUILDING_MYLIB
> > #  define MYLIB_EXPORT BOOST_SYMBOL_EXPORT
> > #else
> > #  define MYLIB_EXPORT BOOST_SYMBOL_IMPORT
> > #endif
> >
> > Using MYLIB_EXPORT for all public symbols in MyLib, and
> > defining BUILDING_MYLIB only when compiling MyLib, will do
> > what you want.
>
> See http://svn.boost.org/trac/boost/wiki/Guidelines/Separate for the
> current guidelines, which most Boost libraries seem to be following.

The #ifdef BOOST_HAS_DECLSPEC surrounds everything, but would be false for GCC, right?

I'd suggest that the BOOST_HAS_DECLSPEC check be managed by the config system so that BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT are defined appropriately (compressed into one place here):

#define BOOST_SYMBOL_EXPORT
#define BOOST_SYMBOL_IMPORT
#define BOOST_SYMBOL_VISIBLE

#ifdef BOOST_HAS_DECLSPEC
#  undef BOOST_SYMBOL_EXPORT
#  define BOOST_SYMBOL_EXPORT __declspec(dllexport)
#  undef BOOST_SYMBOL_IMPORT
#  define BOOST_SYMBOL_IMPORT __declspec(dllimport)
#elif defined BOOST_HAS_VISIBILITY
#  undef BOOST_SYMBOL_VISIBLE
#  define BOOST_SYMBOL_VISIBLE __attribute__(visibility("default"))
#  ifdef BOOST_DEFAULT_VISIBILITY_IS_HIDDEN
#     undef BOOST_SYMBOL_EXPORT
#     define BOOST_SYMBOL_EXPORT BOOST_SYMBOL_VISIBLE
#  endif
#endif

BOOST_HAS_VISIBILITY would be undefined for most compilers, but would be defined for GCC (when __GNUC__ is defined, perhaps after some particular release, but I don't know when it was introduced).

BOOST_DEFAULT_VISIBILITY_IS_HIDDEN must be defined for GCC, when __GNUC__ >= 4, but only if using -fvisiblity=hidden.  I haven't found a way to detect that, so I guess it has to be assumed or defined via the command line.

Then, each library would use this instead:

#define BOOST_WHATEVER_DECL
#if defined BOOST_ALL_DYN_LINK || defined BOOST_WHATEVER_DYN_LINK
#  undef BOOST_WHATEVER_DECL
#  ifdef BOOST_WHATEVER_SOURCE
#     define BOOST_WHATEVER_DECL BOOST_SYMBOL_EXPORT
#  else
#     define BOOST_WHATEVER_DECL BOOST_SYMBOL_IMPORT
#  endif
#endif

Defining BOOST_WHATEVER_SOURCE in each library source file is rather awkward, but it does work.  (I prefer to define that in the build command line via makefile or whatever.  You can't forget it then.)

> >> 2)
> >> What do you think about having BOOST_SYMBOL_EXPORT/IMPORT
> >> always defined?
> >
> > If that's not what's being done -- I haven't looked at the
> > patch itself -- then I agree.  Those macros should always be
> > defined and each library must decide which to use as shown above.
>
> At the moment that isn't being proposed. I'm not against doing that,
> and considered always defining all three of the new macros
> (BOOST_SYMBOL_EXPORT/IMPORT/VISIBLE). That would imply changing all
> compiler config headers, so I'd need help getting them right for
> compilers I'm not familiar with.

While the change I've shown is pervasive, the result is much simpler and cleaner for each library.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.